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

[Trevor Perrin]

On Thu, Nov 9, 2017 at 10:45 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>> 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).

Maybe, but then people will want to switch to it, via negotiation and
compound protocols!


> 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)

NoiseSocket is compatible with different "negotiation_data" contents,
so is agnostic to the question of how you express negotiation choices.

But I agree that defining things in terms of protocol name strings is
a good default approach which I'd like to explore as a layer on top of
NoiseSocket:

https://moderncrypto.org/mail-archive/noise/2017/001331.html

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

Not sure whether you're concerned about Bob-initiated protocols, or
compound protocols in general?

Noise Pipes (used by WhatsApp) are a "compound" protocol.  Any sort of
negotiation or 0-RTT fallback I think should be viewed as a compound
protocol, since the client starts out assuming one Noise protocol,
then the server changes it.  So I wouldn't agree that things work
"great" without compound protocols.

The "Bob-initiated" case is more debatable, special-casing fallback
maybe suffices for most cases.  But I'm not sure it costs much to take
the more general view that a fallback is simply a "Bob-initiated
protocol", and it does buy more flexibility, as in the NX/IN example.


Trevor