[noise] Signatures, and QUIC example

[Trevor Perrin]

On Wed, Mar 25, 2015 at 1:41 AM, Tony Arcieri <bascule at gmail.com> wrote:
> I hope I'm not off-topic here, but I have a general question about
> signatures.
>
> Noise's pure-DH approach to both authentication and key exchange was quite
> appealing to me, but most of the use cases I deal with in practice involving
> TLS tend to include a signature verification chain, and we now always
> leverage an intermediate cert as we try to keep the primaries completely
> offline and put the intermediaries in HSMs.
>
> Should these use cases involve signatures, and if they do, should signatures
> be used in the traditional TLS-style role and D-H only be used for
> exchanging ephemeral keys? In for a penny, in for a pound as you will...


It's a good question - if you have cert chains, then at least one
party has signature verification.

But that doesn't mean signing code is always needed.  And using DH to
authenticate the long-term key means:
 - you're not transmitting an extra signature
 - typically better deniability, though the details matter
 - can reduce ordering constraints (i.e. you can encrypt proactively
based on a DH, you don't have to wait for the signature)
 - includes entropy in the session key from static as well as
ephemeral keys, i.e. can add robustness in case the RNG for ephemeral
key is weak, or ephemeral key gets compromised.

On the flip side, DH-based auth depends on the verifying-party's
ephemeral private key, so is not robust if that key is weak, and not
applicable if you need arbitrary verification (signed prekeys, or
other signed documents).  And the hardness assumptions for DH change
slightly when keys are reused.

Anyways, I generally prefer DH in this sort of protocol *except* for
signed prekeys or statements.  Some people might feel differently, but
if Noise could support both then the debate is less important.


Trevor