[noise] Transport protocol spec finalizing

[Alexey Ermishkin]

Ok, makes sense. But we would still like to simplify handshake parsing and make a clear separation from transport messages.

How about adding those fields (version, negotiation_data len) to the third packet? So that all handshake packets had the same structure.

Will be all zeroes for now but may have some use in future.


So, we'll still have 2 types of packets: 

ClientHello, ServerAuth and ClientAuth:

 - 4 bytes: version
 - 2 bytes: negotiation_len
 - " bytes: negotiation_data
 - 2 bytes: noise_message_len
 - " bytes: noise_message

Transport:
 - 2 bytes: noise_message_len
 - " bytes: noise_message


But from the point of implementers (already talked to them) having a single packet type for handshake will simplify the code.

What do you think?
-----Original Message-----
From: Trevor Perrin [mailto:trevp at trevp.net] 
Sent: Wednesday, July 12, 2017 9:56 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] Transport protocol spec finalizing

On Wed, Jul 12, 2017 at 12:17 PM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> 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)


Comparing to:

https://moderncrypto.org/mail-archive/noise/2017/001161.html

ClientHello and ServerAuth:

 - 4 bytes: version
 - 2 bytes: negotiation_len
 - " bytes: negotiation_data
 - 2 bytes: noise_message_len
 - " bytes: noise_message

Other messages (incl ClientAuth and Transport):
 - 2 bytes: noise_message_len
 - " bytes: noise_message

Differences:

 * I was thinking to include negotiation_data in ServerAuth, so when the server sends server_version != client_version it can optionally send some negotiation_data.  For example, it can send 0xFFFFFFFF along with a list of versions it supports.

 * If noise_message_len is directly before noise_message it's
clear(er) that it gives the length of the noise_message only, not the length of preceding fields.  With your packet_len, I'm not sure if this is the length of all following fields, or only the Noise message?
 If the former (length of entire packet), that means you're reducing the maximum size of the Noise message.

 * If version is at the beginning then it's possible for future versions to change the interpretation of following fields (including length).

 * Not sure this is important, but TLS following a similar
type+length+value format for the record layer and handshake protocol,
e.g. see B.1 and B.3

https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html

 * I'm not sure there's a need to call out the "authentication_tag"
specifically, in the Transport message.  It's true that with current ciphers, the Transport messages end with an authentication tag, but with XX that's also true for ClientAuth and ServerAuth.  It's also possible that future ciphers will use an SIV mode or something else which achieves AEAD encryption without an authentication tag.

Trevor