[noise] Alice and Bob (was Re: NoiseSocket and "reversed" protocols)

David Wong davidwong.crypto at gmail.com
Thu Nov 9 14:45:12 PST 2017

> I think we're all in opposition to the "kitchen-sink" agility of 1990s
> protocols, but I can think of cases where limited agility makes sense:
>  * A server supporting AESGCM for clients with HW acceleration or
> ChaChaPoly for clients without.
>  * A server supporting 448+Kyber for more powerful clients and 25519
> for constrained devices.

Ideally, at some point in time, a single algorithm will run well
enough everywhere (keccak wink wink).
Also, what about negotiating full protocols
("Noise_NX_25519_Chacha20Poly1305_SHA256") instead of negotiating the
crypto inside a protocol? (Or is it what you're already doing? I'm
sorry I haven't had the time to look at Noise Socket yet)

> A "retry request" is not a great alternative to IK/XXfallback ("Noise
> Pipes"), since it adds a whole round-trip in the case that the server
> fails to decrypt the 0-RTT data.
> It's also *not* how TLS 1.3 always handles this - a TLS 1.3 server
> that fails to decrypt the 0-RTT data can transition into a full
> handshake using the client ephemeral (if it is present), just like
> XXfallback.
> If the server rejects the client ephemeral (because the server prefers
> 448 over 25519, for example), then a "retry request" is a simple way
> to handle this, and this is what's in TLS 1.3 and the current
> NoiseSocket spec.

Yeah that is what I meant. HRR is sent for wrong key shares and the
handshake is restarted. If you're talking about 0-RTT I guess I'll
have to read that NoiseSocket spec before commenting on that.

> However I think the NX/IN combination is reasonable, so we should have
> a language for describing this (and perhaps other cases like it).  And
> I think being able to talk about (and compose) Alice-initiated and
> Bob-initiated patterns might get us there.

Well, I never thought I would say that. But on this point, I'm more of
a conservative. Things work great without creating compound patterns,
I don't think this requires more complexity. Yes it's a penalty but
ideally it would be there only for misbehaving clients or clients that
need to be updated if I understand correctly.


More information about the Noise mailing list