[noise] NoiseLink questions

[Rhys Weatherley]

Hi all,

I'm working on Noise for Arduino [1].  I have HandshakeState and friends
working with a direct pattern implementation approach similar to
Wireguard.  I'm coming around to the point of view that direct
implementation is the "correct" way to implement Noise, as opposed to a
full metadata-using implementation that constructs arbitrary protocols at
runtime.  The protocol name parsing and pattern verification code simply
vaporises making the code so much simpler and easier to audit.

I have now begun work on NoiseSocket and NoiseLink and have a few
observations / questions.  Apologies if these issues have already been
raised previously.  Comments are relative to NoiseSocket revision 2draft
(2015-05-01) and NLS revision 2 (2018-03-18).

Section "2.3 Encrypted Payloads" of NoiseSocket is a little unclear as to
the handling of cleartext payloads in handshake messages.  Should they also
have a body_len and padding, or should they be omitted?

Having cleartext payloads with a different encoding complicates things a
little.  WriteMessage() takes in a payload and returns a full message.  At
the point at which the payload is passed in, the caller may not know if it
will eventually be encrypted or not.  If cleartext payloads also had
body_len and (admittedly useless) padding, then the handling is uniform.
Maybe a special case for an empty payload, but non-empty payloads should be
consistent.

NoiseZeroLink should allow transport_options in the first handshake
message.  Otherwise it isn't possible to negotiate continuous rekeying or
smaller packet sizes for the initiator.  The same applies to any other
pattern with two or less handshake messages.

Only NoiseTinyLink appears to allow transport options to be negotiated, but
not full NoiseLink.  How do I select continuous rekey in the full protocol
for example?  Or negotiate smaller packet lengths?

I'd like to argue for the inclusion of packet length negotiation in the
full NoiseLink protocol, not just in NoiseTinyLink.  This allows a
NoiseTinyLink client to be able to communicate with a full NoiseLink server
(assuming the server understands protocol aliases, which isn't a big
imposition).  An embedded device doesn't magically gain the ability to
receive arbitrary-length messages just because the other party is a full
desktop or server implementation of NoiseLink.  I'd like to see
NoiseTinyLink be a strict subset of NoiseLink rather than a different
protocol entirely.

Negotiation of max_send_length and max_recv_length is a little fuzzy.  The
simplest interpretation is "if my send length is greater than the other
party's receive length, then reduce my send length so as not to overflow
their receive buffer".  In fact, I think only one buffer size on each end
needs to be negotiated.  I would reduce it to max_recv_length only with a
policy of "don't send me transport messages larger than this or I'll cut
you off".

There possibly needs to be a minimum specified receive length.  The
absolute minimum is 19: 2 for body_len, 1 for payload, and 16 for MAC.  If
a party attempts to negotiate a smaller size than 19, the connection should
fail.  But even that may be too small because a party could reduce the
other side's send buffer to the point where padding to hide plaintext
length becomes pointless.  I suggest a specified minimum of 32 or 64 or
something like that.

That's it for now.  I'm sure I'll find more as I work through the
implementation.

Cheers,

Rhys.

[1] https://github.com/rweather/arduinolibs/tree/noise/
libraries/NoiseProtocol/src
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180701/1e1c9c27/attachment.html>