[noise] A simple and safe TLS/TCP-like protocol

[Trevor Perrin]

On Sat, Feb 4, 2017 at 1:45 AM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
> I think we can try strings with 1 byte prepending length and see how it
> goes.

Cool.  Agreed that a 255-byte limit on protocol names makes sense
(similar argument as the 65535 message size limit).


[Rhys]:
> I regularly work on embedded chips with RAM sizes of 8K, 20K, 48K, etc.  The
> maximum Noise packet payload is 65535 bytes.  When the IoT device is
> sending, this isn't an issue because it can pick a maximum size that is
> convenient for the device's RAM constraints.
>
> On the receiving side it is a big issue if the sender can choose whatever
> length it likes.  Particularly for message payloads: the MAC must be checked
> before the data is used but the MAC may not arrive within the memory
> constraints of the receiver.

Rhys wants to be able to negotiate a smaller message size limit, for
devices with smaller memory buffers.  Let's talk about that:

As Rhys points out, you want to authenticate the entire ciphertext
message before doing anything with the plaintext.  So even though our
current AEAD schemes (ChaChaPoly, AESGCM) allow one-pass "stream"
processing, a buffered API is safer.  Other AEAD schemes (e.g. SIV
modes like AESGCM-SIV) might require two-pass processing, making them
harder to handle without buffering.

So Rhys wants something like TLS's max_fragment_length extension from
RFC 6066.  I'm not sure what the TLS experience with that has been
(e.g. OpenSSL doesn't support it?).  But maybe it's less important
with TLS given TLS's smaller 16K limit, and typical use cases.

In the spirit of minimalism, let me push back and ask whether
NoiseSocket could work for small devices, without this:

 * Is fragmenting ciphertexts actually sufficient for small-memory
devices?  Isn't it still a problem if the device is receiving and
buffering an excessive *volume* of ciphertext, regardless of how it's
fragmented?  I.e., if there needs to be message size/volume limits in
general, wouldn't that solve this problem more thoroughly than
fragmentation?

 * In typical IoT cases, can't both sides just be configured to send
small messages, or fragment at some hard-coded limit?  Does this need
to be *negotiated*?

 * If negotiation is needed, can't this be left to the application?
I.e., if we allow applications to choose the handshake message
payloads to send certificates etc, they can add their own negotiation.
Then we don't have to burden all NoiseSocket implementations with an
infrequently-needed feature.


Trevor