[noise] NoiseSocket - next steps

[Alexey Ermishkin]

I've added prologue definition to the doc 
https://github.com/go-noisetls/noise_socket_spec/blob/master/noise_socket.md#5-prologue

There's also an example of such a prologue in hex under the spoiler.

Also, added 1 byte type in the second message after the index to separate IK from XXFallback. I did not quite understand what Trevor said about layers, so left just 1 byte for now
-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Saturday, March 11, 2017 12:24 PM
To: Rhys Weatherley <rhys.weatherley at gmail.com>
Cc: Alexey Ermishkin <scratch.net at gmail.com>; noise <noise at moderncrypto.org>
Subject: Re: [noise] NoiseSocket - next steps

On Fri, Mar 10, 2017 at 6:11 PM, Rhys Weatherley <rhys.weatherley at gmail.com> wrote:
> 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.

Good point, but I'd view these bytes as separate layers:
 - The outermost byte indicates the inner protocol
 - If the inner protocol is a Noise Pipe then it has another type byte (but other inner protocols might not)

This would give a nice general framework for negotiation:  The outermost versioning could offer/select any protocol (even non-Noise protocols), as long as they could be named with a string, and have some way of binding the prologue.

But those protocols could do their own signalling within the first round-trip, e.g. if TLS had some extension for binding a prologue we could offer a TLS ClientHello alongside a Noise initial message, and the TLS ClientHello/ServerHello would still have its own negotiation nested within the outer type.


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

For layering, I'd still use separate inner type bytes within a single outer type (we may need better terminology here).


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

Agreed.

Trevor