[noise] NoiseSocket and "reversed" protocols

[Trevor Perrin]

NoiseSocket specifies a framework for negotiation on top of Noise.  The
idea is that each handshake message can contain some "negotiation data"
prior to the Noise message.  The initial message's "negotiation data" can
advertise the initiator's support for other Noise protocols.

The first response message tells the initiator whether the responder is
accepting the initial protocol, rejecting it, executing a "fallback" to a
different protocol that reuses the initial ephemeral, or requesting the
initiator to retry a different protocol.  The response message's
"negotiation data" and "noise message" fields are populated for these
options as follows (Y=populated, n=zero-length):

                   NEGO.DATA    NOISE.MSG
Silent Reject          -             -
Accept                 n             Y
Explicit Reject        Y             n
Retry                  Y             n
Fallback               Y             Y


Note that the responder only has two ways to switch Noise protocol:
 - Fallback = switch to a protocol that reuses the inital ephemeral
 - Retry ("reinitialization request" in current spec) = ask the initiator
to start a new protocol

That covers most cases.  If the responder accepts the initiator's DH
choice, it uses a "fallback" protocol.  If the responder doesn't accept the
DH choice, it's simplest to ask the initiator to retry the same pattern
with the correct DH.

However, in some cases it might be more efficient for the server to reject
the client's DH choice but simultaneously initiate a new protocol on its
own.  For example-

Client attempts NX_25519:
 -> e
 <- e, ee, s, es

If the server asks for a retry with NX_448, then we lose a whole
round-trip, and the client can't send encrypted data till her 3rd message:

 -> e[25519]
 <- RETRY PLEASE WITH 448
 -> e[448]
 <- e, ee, s, es
 -> ENCRYPTED_TRANSPORT_MESSAGE

If the server is willing to send its identity in clear, then the client can
send some encrypted data on her 2nd message:

 -> e[25519]
 <- RETRY WITH:  e[448], s
 -> e, ee, es, ENCRYPTED_PAYLOAD

The "reversed" part of that looks like an IN pattern with roles reversed.

IN:
 -> e, s
 -> e, ee, se


So for completeness, I wonder if we should extend NoiseSocket so the
responder also has a "Reverse" option?

                   NEGO.DATA    NOISE.MSG
Silent Reject          -             -
Accept                 n             Y
Explicit Reject        Y             n
Retry                  Y             n
Fallback               Y             Y
Reverse                Y             Y

I'm not sure whether we'd view this as just a role reversal followed by IN,
or a "modified" IN, such as:

INreversed:
 ->
 <- e, s
 -> e, ee, es


Thoughts?


Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170929/9736c569/attachment.html>