[noise] QUIC + Noise = nQUIC

[david wong]

Hey Trevor,

I’ll try to answer your questions inline. The other authors are on the list if they want to chime in ;)

> Nice work, a few questions:
> 
> * 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


> 
> * 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. 



> 
> * The paper discusses the rationale for choosing Noise if you've
> already decided to use QUIC, but it doesn't give as much rationale for
> choosing QUIC if you've already decided to use Noise.  The paper says
> "nQUIC is not intended for the traditional web setting", so for what
> users or use cases do you think nQUIC might be useful, outside of the
> web?

I guess if you’re using Noise, you’re probably  trying to solve a problem with a transport layer you already have. The scenario we’re talking about is real: people want to use QUIC because it is fast but they don’t necessarily want to use it with TLS. Use case we’re thinking about is applications in machine to machine communication. So think QUIC on top of wireguard for two applications that want to talk. 


> 
> * The code is still listed as a work-in-progress, what is the status
> of that?  Also, any interest in creating a Noise extension spec for
> this?

I think the priority now is to make it as an RFC that looks like the QUIC-TLS one. The main QUIC RFC is referencing TLS a lot at the moment though. 

Hope that answers your questions,
David