[noise] NoiseLink questions

[Trevor Perrin]

On Sun, Jul 1, 2018 at 3:45 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> 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.

My hope is that code-generators could combine the flexibility of
names/patterns/modifiers with simple/auditable outputs.  Someday!


> I have now begun work on NoiseSocket and NoiseLink and have a few
> observations / questions.  Apologies if these issues have already been
> raised previously.

Nope, this is great - these are untested and unstable specs in
desperate need of feedback...

(Also, Gerardo and I are discussing this renaming, if you have opinions:

https://moderncrypto.org/mail-archive/noise/2018/001594.html
)


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

Only encrypted payloads should have those things (for padding).


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

You want padding, even for cleartext payloads?  Seems like a slight
waste of bytes.  I assume implementations can combine decryption with
de-padding, and that's clean enough?


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

This gets into a good cluster of questions:  There's a lot about
TransportOptions and the default profiles that we need to think on...


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

As of now, you don't.  NoiseLink was intended as a simple starting
point for Internet protocols.  You could modify the NoiseLink profile
to include those things if you need them, but your typical Internet
protocol doesn't.


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

That's worth considering (making NoiseTinyLink a subset of NoiseLink).
NoiseTinyLink has some tweaks and compromises to support constrained
devices though.  So we need to think about the cost of imposing those
on NoiseLink:

 * Aliases ("1", "2", "3"):  Not a big deal to impose.

 * Rejected-retry:  This is a more dangerous but cheaper way to do
negotiation, because the new handshake doesn't bind all of the
previous handshake, it only names the previous initial_protocol.  But
it's not that costly to impose (the server just checks that the
rejected_protocol isn't one that it would accept).

 * max_send_length / max_recv_length:  Not normally needed for an
internet protocol.  But not that hard to implement, either.

 * BLAKE2s: was specified for NoiseTinyLink, but not NoiseLink.
Rationale was that SHA256 is everywhere, so it makes sense for
Internet devices.  For tiny devices maybe the efficiency advantage of
BLAKE2 would make a difference.  But on considering this, I'm not sure
it's worth it.  There are better symmetric-crypto optimizations we
could do for small devices (non-HMAC/HKDF; unifying the ck and h
chains; coalescing repeated MixHash inputs into a single hash block;
Keccak/STROBE/Disco etc).  So maybe we should just stick with SHA256
for the default profiles, until we've spec'd these other things.


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

That's true; if you advertise a max_send_length the receiver can
allocate a smaller buffer, but maybe that's not worth the effort.  We
could take it out of NLS entirely, or just not use it in the default
profiles?

This bring up another problem w/TransportOptions:  There's no way to
advertise/negotiate which options you support.  You have to know in
advance whether the other side is able to accept your options.

If we expect to have a small number of options, we could possibly just
add a uint32 bitfield to TransportOptions saying which options you
support (it will be encoded as a varint, so typically smaller than 4
bytes).  Each party can send whatever options it wants, but it will
only assume the other party accepted the option if it receives a
bitfield with the appropriate bit set.

?


Trevor