[noise] NoiseSocket - next steps
trevp at trevp.net
Fri Mar 10 23:24:27 PST 2017
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