[noise] Transport protocol spec finalizing

[Trevor Perrin]

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
>