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

[Trevor Perrin]

On Thu, Nov 9, 2017 at 3:29 AM, Trevor Perrin <trevp at trevp.net> wrote:
> On Fri, Sep 29, 2017 at 2:37 AM, Trevor Perrin <trevp at trevp.net> wrote:
>
>> So for completeness, I wonder if we should extend NoiseSocket so the
>> responder also has a "Reverse" option?
> [...]
>> I'm not sure whether we'd view this as just a role reversal followed by IN,
>> or a "modified" IN, such as:
>
>
> I'll try to summarize this issue, and make a proposal:
>
> Background
> -----------
> A Noise protocol is a fixed, "linear" sequence of messages and crypto
> ops.  There are no runtime decisions, except aborting on errors.  This
> keeps things simple.
>
> However, some situations might require "branching" (negotiating
> protocol versions or crypto choices; 0-RTT fallback).
>
> So far we've viewed that as switching from one "linear" Noise protocol
> to another (e.g. switching from IK to XXfallback, if the server can't
> decrypt the 0-RTT IK message).
>
> I like how this confines runtime decisions to a single point:  What
> Noise protocol are you executing?  You might switch from one protocol
> to another, but aside from that, everything else has the simplicity of
> a "linear" protocol.
>
>
> Problems
> --------
> There's a terminology question:
>
> If a "Noise protocol" is a linear protocol (like
> "Noise_XX_25519_SHA512_AESGCM"), then what is a "Noise Pipe" (where a
> server supports XX, as well as IK with XXfallback)?  I'll tentatively
> call it a "compound protocol".
>
> There's also a notation issue:
>
> 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.
>
> Our current spec treats fallback patterns as a special case where the
> responder sends the first message, allowing us to describe the
> IK/XXfallback sequence without flipping the message direction:
>
> IK(s, rs):
>     <- s
>     ...
>     -> e, es, s, ss
>     <- e, ee, se
>
> XXfallback(e, s, rs):
>     -> e
>     ...
>     <- e, ee, s, es
>     -> s, se
>
> However there are non-fallback cases were the server might initiate a
> new Noise protocol.  My previous message described a client attempting
> NX_25519, and the server responding by initiating IN_448.
>
> Given this, special-casing "fallback" seems like a limited solution we
> should replace with something more general.
>
>
> Proposal
> ---------
> We could name the parties "Alice" and "Bob", and have right-pointing
> arrows represent messages from Alice to Bob (and vice versa):
>
>  Alice -> Bob
>  Alice <- Bob
>
> In a simple Noise protocol, Alice is the initiator (initiator =
> whoever sends the first message).
> In a compound protocol, Alice is the initiator in the first Noise protocol.
>
> Handshake patterns could be written in either Alice-initiated form
> (the default), or Bob-initiated.  Converting from one to the other
> requires reversing arrow directions, and changing "se" <-> "es".
>
> For example, here is the N pattern as Alice-initiated, then as Bob-initiated:
>
> N(rs):
>     <- s
>     ...
>     -> e, es
>
> N(rs):
>     -> s
>     ...
>     <- e, se
>
>
> Now we can write Alice-initiated NX and Bob-initiated IN, and it's
> easier to read what happens if Bob rejects Alice's initial NX message
> and initiates IN in response:
>
> NX(rs):
>     -> e
>     <- e, ee, s, es
>
> IN(s):
>     <- e, s
>     -> e, ee, se

Gah, typo - flip the last "se" to "es", so the whole thing reads:

NX(rs):
    -> e
    <- e, ee, s, es

IN(s):
    <- e, s
    -> e, ee, es


Trevor