[noise] Draft extension: Authentication of handshake data between messages

[str4d]

On 06/10/2018 04:14 AM, Trevor Perrin wrote:> One concern:  I'm not sure
we understand the use-cases for this
> feature yet.  In particular, I think str4d's case involves appending
> variable-length padding onto a fixed-length Noise message:
> 
> """
> - Read a fixed-length encrypted Noise message from the network.
> - Call ReadMessage() to get the Noise plaintext.
> - Extract a length field from the Noise plaintext.
> - Read that many bytes from the network.
> - Call AuthenticateData() with those bytes.
> """
> 
> I don't quite understand where this is useful, does it have to do with
> censorship-circumvention, and is there some trial-decryption involved
> in ReadMessage()?

The goal of the above use-case is to enable the "handshake messages"
(Noise + surrounding data) to be variable-length, in order to remove a
trivial protocol fingerprinting attack (measuring the sizes of the
handshake packets). This requires providing a length field in a
fixed-length part (which is read and parsed first), followed by a
variable-but-now-known-length part. There is no trial-decryption
involved, because the length of the payload containing the first part is
fixed by the Noise protocol name.

I see two ways to achieve this:

1) Make the variable-length part a second handshake payload.

- The first payload would just contain a fixed-size length field.

- Requires an optional additional payload in any handshake message,
which can be handled outside of ReadMessage() (because it can't be
fully-read until ReadMessage() returns the contents of the first payload).

- Adds 16 bytes of overhead if the variable-length data doesn't need to
be encrypted. This isn't a performance concern in the padding case,
though it does increase the minimum packet size which could potentially
make more advanced active packet-size distribution analysis easier (but
that's out-of-scope for Noise).

2) Place the variable-length part outside the Noise message.

- Length field goes into the existing fixed-size Noise payload (along
with other data desired to be conveyed in the first handshake message).

- Requires that the variable-length data is unencrypted (because it is
outside the Noise message, and there is no other key material yet),
which is perfectly fine for padding.

- To prevent the creation of an oracle, modifications to the
variable-length part outside the Noise message should cause the
handshake to abort. This requires authenticating the data, which is
where this draft comes in.

Either strategy involves doing protocol-relevant operations outside
WriteMessage() and ReadMessage(), but 2) only requires a call to
MixHash(), so it seemed much simpler to handle as an extension.

Note that this is only needed for handshake messages 1 and 2. The length
of message 3 (if it exists) can be specified inside the existing payload
of message 1, so any padding there can be applied inside the payload.

> 
> Also, for this use-case, you'd want the authenticated-data to come
> after the payload, but for PSKs we assumsed "pskX" applied the PSK to
> the end of the tokens, but it was processed before the payload.  So
> far we've always considered the payload coming at the end, after all
> the tokens for a message pattern have been processed.

Yep, this does make things somewhat less tidy. It might be possible to
notationally have it apply to the beginning of the next message (i.e
message pattern 2 starts by authenticating the data that was tacked onto
the end of message 1), though that in turn means that the data processed
by a particular message pattern isn't all from the corresponding network
data blob. But if Noise doesn't care where the authenticated data comes
from, then this could be a way to keep the extension in line with the
existing specification.

Cheers,
str4d

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180610/bebf078c/attachment.sig>