[noise] NoiseSocket - next steps
scratch.net at gmail.com
Mon Mar 13 01:16:41 PDT 2017
I've added prologue definition to the doc
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
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.
More information about the Noise