[noise] Transport protocol spec finalizing

[Alexey Ermishkin]

I've added some fixes, though not all of them. Same url. 

Also some news - turned out that NoiseLink is a trademark of SoundCloud, so looks like we get less options here.

-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Tuesday, July 18, 2017 10:12 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Transport protocol spec finalizing

Good start, I like that it's simple and short.


Overall comments:
------------------
In terms of organization, you might think about either/or:
 * An Overview section at the beginning which informally describes things.
 * Moving the examples to a separate section at the end.

These might let you separate the normative text (describing exact data structures and algorithms) from the usage discussion.

Sometimes it also makes sense to separate out data structure descriptions (Handshake message, Transport message) from algorithm descriptions.

There's a negotiation algorithm here that should probably be more explicit:

If noise_message is non-empty:
  - If negotiation_data is empty, the sender accepted the previous Noise protocol
  - If negotiation_data is non-empty, the sender has switched to a different Noise protocol

If noise_message is empty:
 - The sender is rejecting the previous Noise protocol, and can send error or retry data in the negotiation_data. The sender may leave the connection open so the recipient can try again.

You only discuss the case where the server starts a new protocol, but it should also be possible for the server to send more negotiation data, and for the client to start a new protocol in the client's 2nd message.


Detailed comments:
-------------------

Abstract - Noise (and NoiseSocket) are compatible with certificates, and the concept of certificates is not as bad as the X.509 implementation that TLS uses.  So instead of talking about cases without certificates, you might talk about cases where "X.509 infrastructure isn't required".

1. Could add a little more explanation of Handshake vs Transport messages.

1.1. Could clarify that the length fields apply to the following fields.

1.1. The Noise details here I could imagine being moved to an Overview or Examples section.

1.1.1.  The example you describe doesn't offer different choices from the client, it might be good to show that.

1.2. Clarify that padding contents are arbitrary, and must be ignored by the recipient.

2. Seems like this could be described more generally in terms of a "handshake transcript", so that it extends to handling the prologue when the client starts a new protocol, as well.

5.
 - Fix numbering
 - There's probably an InitializeServer and Reinitialize functions as well.
 - The INPUT is not necessarily a "cleartext" body, that's only true for first message.
 - Clarify behavior of padded_len
 - Give an example of calling sequence.  Or maybe do this in an Examples section.

Trevor


On Tue, Jul 18, 2017 at 12:02 PM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> So, the draft is here:
> https://github.com/noisesocket/spec/blob/master/output/noisesocket.pdf
>
> Comments are very welcome.
>
>
>
> -----Original Message-----
> From: Trevor Perrin [mailto:trevp at trevp.net]
> Sent: Friday, July 14, 2017 10:46 PM
> To: Alexey Ermishkin <scratch.net at gmail.com>
> Cc: noise <noise at moderncrypto.org>
> Subject: Re: [noise] Transport protocol spec finalizing
>
> On Fri, Jul 14, 2017 at 8:56 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
>> Yep, totally agree
>
> Cool, this is getting nice and simple.
>
> It seems like we're ending up with a "NoiseSocket" (or whatever) that just adds a simple negotiation and padding framework, where a higher-layer protocol is going to fill these in by choosing:
>  * Encoding for payloads and negotiation_data (eg protobufs)
>  * Noise patterns (eg XX)
>  * Versioning (eg maxVersion+minVersion; different enumerated fields; 
> centralized registry versus application-specific)
>  * Authentication (e.g. certificates)
>
> I wonder if the NoiseSocket API should also be more generic?  E.g., maybe it should just use functions like ReadHandshakeMessage / WriteHandshakeMessage.  It would be for the higher-layer protocol and API to assign more specific meanings (ClientHello, ServerAuth, ClientAuth)?
>
>
> Trevor
>