[noise] Transport protocol spec finalizing

[Trevor Perrin]

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