[noise] NoiseSocket - next steps

[Rhys Weatherley]

On Wed, Mar 8, 2017 at 5:15 PM, Alexey Ermishkin <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/3d6937b7/attachment.html>