<div dir="ltr"><div>Hi all,</div><div><br></div><div>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.<br></div><div><br></div><div> 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).<br></div><div><br></div><div>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?<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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?</div><div><br></div><div>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.<br></div><div><br></div><div>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".<br></div><div><br></div><div>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.<br></div><div><br></div><div>That's it for now.  I'm sure I'll find more as I work through the implementation.<br></div><div><br></div><div>Cheers,</div><div><br></div><div>Rhys.</div><div><br></div><div>[1] <a href="https://github.com/rweather/arduinolibs/tree/noise/libraries/NoiseProtocol/src" target="_blank">https://github.com/rweather/<wbr>arduinolibs/tree/noise/<wbr>libraries/NoiseProtocol/src</a><br></div></div>