[noise] Transport protocol spec finalizing

[Alexey Ermishkin]

1) negotiation_data in ServerAuth - accepted.

2) Yes, we reduce the noise_message length, but we also set the upper bound on the buffer size needed to process any of the incoming packets which seems like a good value to me.  
Otherwise it can grow up to 65535*2 + 8 bytes. Which is probably not so good for high loads and IoT guys. 

This can further be expanded to the second packet using the version field (or any other technique) which we'll have to do anyway if we exceed the 65k limit with post-quantum keys or long certificate chains

Spec would  clarify what that length means and calculating the last message part is a first-grade math complexity. At least for those who will implement the protocol. We use the similar approach with padding anyway.

Otherwise I like the idea of having only two different message structs.

3) Do not mention authentication tag - accepted

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