[noise] Transport protocol spec finalizing

[Alexey Ermishkin]

Some corrections on packet structure:

We suggest that each packet including handshakes start with the "length" field, so that the packet parsing code would not dramatically change from packet to packet. Thus, structs will look the following way:

ClientHello:

 - packet_len (2 bytes)
 - client_version (4 bytes)
 - negotiation_data_len (2 bytes)
 - negotiation data
 - remaining bytes: noise message

ServerAuth:

 - packet_len (2 bytes)
 - server_version (4 bytes)
 - remaining bytes: noise message

ClientAuth:

 - packet_len (2 bytes)
 - noise message

Transport message:
 - packet_len (2 bytes)
 - encrypted data
 - authentication tag (16 bytes)

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

On Mon, Jul 10, 2017 at 8:07 AM, Scratch <scratch.net at gmail.com> wrote:
> So, looks like we agreed on the handshake part. It looks pretty 
> lightweight and extendable at the same time.

Yeah, I think the discussion has stabilized enough that we should specify and implement this, and see what we learn.


> Things that are to be finalized:
>
> - Padding. The latest proposal about having 2 bytes length .. n bytes 
> padding inside payload looks good to me

Specifically:
 - 2 bytes: body_len
 - body_len bytes: body
 - remaining bytes: padding

(So that the body is always in the same offset at the start of payload, maybe easier to process).

This still seems fine to me.  I think we should probably put this only in the encrypted payloads though, not the cleartext ClientHello payload.

The rationale for that was that the padding could server as an additional area for negotiation data, but since we now have an explicit negotiation_data field, and the ClientHello cleartext payload itself, I don't think we need a 3rd area, and it seems cleaner to only pad the encrypted payloads.


> - Name. NoiseLink is Ok, though on DEF CON it's already NoiseSocket 
> https://cryptovillage.org/dc25/schedule.html so we'll need to say smth 
> about it.

Let's think on this a little more (is there any deadline for updating the DEF CON material)?  If we don't think NoiseLink improves on NoiseSocket that much we could consider leaving it.

One point: I strongly think you should avoid statements like "NoiseSocket changes Transport Layer Security #TLS", or "enables quick and seamless Transport Layer Security (TLS)".

TLS isn't a generic term, it's a specific protocol.  We need to be clear that NoiseSocket and TLS are different protocols.


> - API. Same as in Trevor's proposal
> https://moderncrypto.org/mail-archive/noise/2017/001135.html
> adjusted to our latest agreements.

Yeah, it will need some adjustments, and maybe there should be a PeekClientHello.


> Thoughts?
>
> I could start a spec if there's no objections

Sure, I might try a writeup as well in next week or so, if I have time, and we can compare them and take the best pieces, or merge in some way.

Trevor