[noise] NoiseSocket - next steps

[Rhys Weatherley]

On Sat, Mar 11, 2017 at 8:17 AM, Trevor Perrin <trevp at trevp.net> wrote:

> We'd have to disallow that, the server would be required to first
> choose the handshake message it's responding to (IK), and then do
> XXfallback if it wants.
>

The issue with that is right now NoiseSocket cannot indicate whether the
server is responding to IK or it has switched to XXfallback.  Suggest
changing the single-byte index to a two-byte field.  The first is the index
and the second is a "type" byte.

For most protocols, the "type" must be zero.  For Noise Pipes, the "type"
byte follows the conventions from section 9.2 in the Noise specification: 0
indicates a normal response to IK and 1 indicates a switch to XXfallback.

Section 9.2 also lists conventions for type bytes from the initiator, but
we don't need that here.  The client chooses full vs abbreviated handshakes
by populating the protocol list with XX or IK patterns respectively.

A server that does not support Noise Pipes will simply fail the IK
handshake and close the socket rather than switch.

I'm still a little hesitant on leaving transmitted data out of the
handshake hash, but I can live with it if there is a clear method to
support fallbacks in NoiseSocket.

That still leaves the prologue definition.  The specification needs to
clearly define what data from the first handshake packet is concatenated to
form the prologue.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170311/8c5f8fb0/attachment.html>