[noise] NLS?

[Gerardo Di Giacomo]

Hi Trevor,

Question about the retry/switch part.

I’m trying to implement the NoiseLingo (NoiseLink/NoiseZeroLink) on the current NoiseSocket (NS) implementation in go (https://github.com/go-noisesocket/noisesocket).

A couple of notes:

1) In NLS you have: "If the responder accepts the initiator's initial_protocol, the response negotiation_data is zero-length (according to NoiseSocket).” Currently the negotiation data for both initiator and receiver is saved in the Prologue. If the negotiation data for the responder has to be zero-length, and therefore the Prologue is empty, then the handshake will fail, as "If both parties do not provide identical prologue data, the handshake will fail due to a decryption error.” Currently, with the go implementation of NS, the responder replays the same negotiation data + its noise message to the initiator. Which leads me to the second note…

2) For NS, the Prologue’s initial string was NoiseSocketInit1/2/3 according to where you were in the handshake (accept, switch, retry). So if, as initiator, I received a Init2, I knew I had to read more bytes because I knew I was going to receive the responder’s negotiation data as a “fourth” packet (1- NoiseSocketInit2, 2- negdata(len+content), 3- noise(len+content), 4- Rnegdata(len+content)). With NLS you have the same initial string "NLS(revision1)”, and since the responder’s first three packets are basically the same, as a initiator I don’t know if I have to read the 4th packet containing responder's negotiation data or the responder accepted the protocol.

(Hopefully I was clear enough…)

Maybe I’m missing something somewhere, but it’s not clear to me how I’m specifically supposed to handle accept, switch and retry during the initial negotiation.

Gerardo

> On Mar 7, 2018, at 9:47 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> On Thu, Mar 8, 2018 at 4:50 AM, Gerardo Di Giacomo <gedigi at live.com> wrote:
>> Thanks again for sharing this Trevor. I’ve started some experiment in integrating NLS (NoiseLink/NoiseZeroLink) to the existing implementation of NoiseSocket. I’ll share updates as I make progress.
> 
> Cool, I'm going to start an implementation too.
> 
> 
>> As I was initially reading the spec, I though whether, for sake of simplicity, would it make sense to merge NoiseLink and NoiseZeroLink in a single profile (ZeroLink)? They both share the same negotiation fields, so it might be easier from an implementation/interop standpoint to have a single profile that offers both 0 and 1 RTT.
> 
> Ah, the text wasn't clear:  Yes, NoiseZeroLink is a superset of
> NoiseLink, so they can definitely interop, in either direction
> (NoiseLink client -> NoiseZeroLink server, or vice versa).
> NoiseZeroLink is another name for "Noise Pipes" from the Noise
> specification, but that name only makes sense historically, which is
> why I'm trying to move away from it.
> 
> Hopefully this text is clearer:
> 
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnoiseprotocol%2Fnls_spec%2Fblob%2Fmaster%2Foutput%2Fnls.pdf&data=02%7C01%7C%7C9b55e21c46b644969c1008d584b825cb%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636560848799436344&sdata=VZWcYrotHHZ2erFUrZ1Wn%2FZe%2FRHnpNEY7F4XipM%2FatU%3D&reserved=0
> 
> Trevor