[noise] QUIC + Noise = nQUIC

[david wong]

I think the flexibility discussion is a good one to have. Or at least, what would be the best way to allow flexibility if we want to introduce it later? Different QUIC versions could mean different handshake patterns, or we could use noise lingo. 

As per the complexity of the DH ratchet, it was actually one of the big requirement for nQUIC: no DH ratchet if we can’t implement it in a few lines of code. Turns out it is almost free to have it in the protocol VS implementing a system to restart a handshake without losing a session. Some of our main use cases included long lived sessions so this was also important to us. 

IX-wise. Privacy of the identities here are not part of the use cases we thought about. If you want extra privacy for the “public” keys, you’re going to have to use Noise in an ad-hoc way. Which is the beauty of Noise. If we go with Trevor’s way, then it’ll support any Noise pattern so I hope that won’t be too offensive to you :)

David


> On Dec 17, 2018, at 9:42 AM, dawuud <dawuud at riseup.net> wrote:
> 
> 
> Hi, I just wanted to share some opinions on these topics:
> 
> I find the use of the IK handshake to be rather offensive and socially irresponsible.
> I certainly would never use any IK handshake in any of my mixnet projects.
> 
> I don't like wireguard at all.
> 
> QUIC seems cool although I dislike TLS and would never use it in any of my mixnet projects.
> 
> Cheers,
> David
> 
> 
>> On Mon, Dec 17, 2018 at 04:34:36PM +0000, Trevor Perrin wrote:
>> 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
>> _______________________________________________
>> Noise mailing list
>> Noise at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/noise