[noise] NoiseSocket - next steps

[Trevor Perrin]

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