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

[David Wong]

>> However, some situations might require "branching" (negotiating
>> protocol versions or crypto choices; 0-RTT fallback).

Isn't "crypto choices" something we want to avoid? agl posted about
this in what he calls "crypto agility" (this might have been discussed
on the list before but I missed that :D)

>> In a "compound protocol", it's not clear how to handle the roles of
>> "initiator" and "responder".  For example, if the client initiates a
>> connection to the server and sends an IK message that the server can't
>> decrypt, the server will be "initiating" the XXfallback.  But since
>> initiator-sent messages are notated with right-pointing arrows,
>> reading IK and XXfallback back-to-back would be confusing if we didn't
>> do something to prevent the client<->server message direction from
>> flipping.

Why not just have the server send some "retry-with-protocol-X"
message, which will make the client re-start a new handshake with a
different pattern.
This is what TLS 1.3 does at the moment, the server sends a hello
retry request if it's not satisfied with the client hello, and the
handshake basically restarts. It's a penalty but it keeps things
simple and easy to analyze.

(I think they're thinking of merging the HRR in the server hello so
this might change, but currently that's what it's doing)

David