[noise] Transport protocol spec finalizing

Trevor Perrin trevp at trevp.net
Wed Jul 12 09:55:58 PDT 2017

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:


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


 * 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

 * 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


 * 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.


More information about the Noise mailing list