[noise] NoiseSocket - next steps

[Alexey Ermishkin]

Hi Rhys and thanks for your comments.

 

Actually, the padding is encrypted after the handshake completes. I just did not make it clear in the doc. Everything except the length is encrypted.

 

I will also remove the padding from the handshake, it was there just to generalize packet parsing.

(already fixed in the doc)

 

And one more change, discard the “The amount of sub-messages is stored in a 1-byte value N, right after padding.” paragraph. The “while <not the end of the packet> loop” works ok, so this field does not seem to be needed.

 

I also like the idea of message fields. They will be very useful for re-negotiating. Will try to add them this week

 

From: Rhys Weatherley [mailto:rhys.weatherley at gmail.com] 
Sent: Thursday, March 09, 2017 12:49 AM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: noise <noise at moderncrypto.org>
Subject: Re: [noise] NoiseSocket - next steps

 

On Wed, Mar 8, 2017 at 5:15 PM, Alexey Ermishkin <scratch.net at gmail.com <mailto:scratch.net at gmail.com> > wrote:

And a kind of protocol description
https://github.com/go-noisetls/noise_socket_spec/blob/master/noise_socket.md

 

Here are some initial comments.

 Section 1:

"Noise Socket is a secure transport layer protocol that is much simplier than TLS, easier to implement and does not require certificates. Only raw public keys can be used to establish secure connection."

The first sentence implies that certificates are optional - use them only if you want to.  The second sentence implies that certificates are explicitly disallowed in favour of raw public keys only.  Re-wording:

"Noise Socket is a secure transport layer protocol that is much simpler than TLS and easier to implement.  The communicating parties are identified
by raw public keys, with the option to provide certificates during the
initial handshake." 

Section 4:

I don't particularly like that padding is outside the encryption layer and not covered by the MAC.

"Padding aligns payload to a certain predefined size to make packets indistinguishable from each other."

Except that this packet format doesn't quite do that.  One of the purposes of padding is to hide the length of the plaintext so that the attacker doesn't gain any information from "8 bytes were sent in the first packet, 5 in the second, 13 in the third".  With the padding length in the clear, there's no value in adding the padding.

I think padding should be left to the application layer.  So I would remove PDs and PD from the packet format and we'll deal with it elsewhere.

Otherwise, the spec so far looks implementable.

Onto the application layer.  While it is tempting to say "left up to the application to decide", I think we may want to define a reference format.  Here's a possibility:

------
The application packet format consists of zero or more message fields, followed by padding.  Each field consists of:

    2 bytes for field length, including the message type
    2 bytes for message type
    field payload data

The minimum field size is 4 bytes (0 bytes of field payload data).  The total size of all fields must not exceed Ps - MACsize.

Message types 0 to 1023 are reserved for use in this and future versions of the NoiseSocket specification.  Message types 1024 to 65535 are application-defined.

This version of the specification defines message type 0 as padding.  The field payload data is ignored and should contain random bytes.  If the overall message length would have 1 to 3 bytes left over once all fields are parsed, those bytes will also contain random padding without a field header.

Message type 1 is assigned to the primary data channel within the session if the application does not have its own way of identifying separate channels.

A minimal implementation of NoiseSocket supports message types 0 and 1 to provide a TLS-style transparent data link.  More complex applications may forbid the use of message type 1 and use their own message types for identifying separate channels of communication.  Padding must always be supported.

This format is also used in handshake message payloads if the payload size is non-zero.
------

This provides some flexibility in the future to define message types 2, 3, and so on for certificate blobs, maximum message size negotiation, etc.

Cheers,

Rhys.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170309/5ed5404e/attachment.html>