[noise] Comments on the specification

[Rhys Weatherley]

A few minor comments as I've been working on Noise-C.

My background is in embedded systems.  My most recent pre-Noise project is
a set of cryptographic primitives for Arduino [1], so I'm very familiar
with the problems in that space.

Under section 12, "Application Responsibilities", it is mentioned that
length fields can be up to 65535 bytes and a 16-bit big-endian packet
length field should be prepended.

Which is fine ... except that won't always work in the embedded space.
Systems I use regularly have 8K, 20K, or 96K RAM sizes.  So a full Noise
packet at maximum length either won't fit, or it will use so much RAM that
there's nothing left over for the application.

It's important to remember that an IoT device has some specific function to
perform: control a thermostat, poll sensors in a data logger, or whatever.
This is the main purpose of the device and security needs to fit around
that.  The security doesn't own the device - the purpose does.

Fortunately the code size of the Noise protocol is pretty good, which
should fit in typical embedded flash memory sizes (flash is cheap in this
space).  But the buffer sizes and the cipher/hash/DH state sizes can put a
lot of pressure on the not-so-cheap RAM.

The sending side is not a hassle.  It's the receiving side where the other
party can send requests that are too big to be processed.  I suggest adding
some text to section 12 indicating that applications may need to negotiate
the maximum packet length that a receiver is willing to accept.

There will of course need to be a minimum limit as well because the Noise
protocol cannot operate on packets too small to contain the handshake.
"Noise implementations must be able to handle packets of at least N bytes
in length, and may negotiate a maximum length of N or greater".  For some
value of N.

On the subject of "Application Responsibilities" again, there are a lot of
good recommendations there.  I would like to see "reference protocols" for
UDP and TCP transports, and for one-way offline traffic (e.g. file
encryption).

If the application author doesn't have any specific preferences then they
can use the reference protocol and be reasonably confident that they won't
make a mistake in padding schemes or whatever.  This may involve defining
specific type field values, algorithm negotiation prologues, and padding
schemes.  Separate specification possibly.

I'll need to make some examples for Noise-C.  I could probably invent
something to test out reference protocol ideas.

Cheers,

Rhys.

[1] http://rweather.github.io/arduinolibs/crypto.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160410/89f42996/attachment.html>