[noise] QUIC + Noise = nQUIC

[Trevor Perrin]

On Mon, Dec 17, 2018 at 4:15 PM david wong <davidwong.crypto at gmail.com> wrote:
> >
> > * You've focused on the IK handshake, how easily could this be
> > extended to other Noise handshake patterns?  The efficiency reasons
> > for wanting QUIC transport seem pretty independent from the reasons
> > for choosing one Noise handshake or another.
>
> We went back and forth about supporting several handshake patterns or not. In the end the IK was versatile enough for the use cases we were thinking about, and it goes in line with the “keep it simple” philosophy. Now in practice, you could think of using any  handshake patterns and it would work, keys are exported only at the end and order of the packets is given by QUIC. We’ve re-worked the types of keys we end up giving to QUIC so that integration is easier: just use a Noise library and export the handshake messages in initial QUIC packets, then export keys at the end

It sounds like technically this could be pretty orthogonal, and the
reasons you'd want QUIC, or want a particular Noise pattern, are
pretty orthogonal as well, so it would be nice if the handshake
pattern was a choice.

It's easy to imagine applications where server's identity key isn't
preknown but delivered through a certificate, or where client would
prefer forward-secrecy for identities, or where client doesn't
authenticate or uses a password or something.


> > * Is the double-ratcheting thing part of QUIC, or is that something
> > you did just for nQUIC?  If the latter, I wonder if the complexity is
> > really justified, or if you could just use Noise's "rekey"
> > functionality.
>
> This is just for nQUIc and it brings backward secrecy, which REKEY does not. It is similar to what Wireguard does.

I think WireGuard just does a new handshake, so this isn't really
similar to that.  Is it similar to how QUIC/TLS operates, or is it
easy to just do a new handshake?  If the latter, I'm still wondering
if the complexity is justified.


Trevor