<div dir="ltr"><div>A few minor comments as I've been working on Noise-C.<br><br></div><div>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.<br><br></div><div>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.  <br><br>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.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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.  <br><br>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.<br><br></div><div>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).<br><br>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.<br><br></div><div>I'll need to make some examples for Noise-C.  I could probably invent something to test out reference protocol ideas.<br></div><div><br></div><div>Cheers,<br><br></div><div>Rhys.<br><br>[1] <a href="http://rweather.github.io/arduinolibs/crypto.html">http://rweather.github.io/arduinolibs/crypto.html</a><br><br></div></div>