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

[Rhys Weatherley]

On Sat, Feb 4, 2017 at 8:33 AM, David Wong <davidwong.crypto at gmail.com>
wrote:

> > From the IETF/TLS experience, I'm pretty opposed to global number
> registries. It adds a lot of friction when everyone has to negotiate with
> authorities to get their numbers assigned
>
> this ^
>
> This would hurt the simplicity of Noise so much. Strings are fine, and
> they make reading the code easily.
>

I'm "Team String" as well  As Trevor points out, it is much easier for
experimenters to pick a name and get going without waiting for the rubber
stamp first.

Strings do have one drawback though - they are arbitrary-length which can
be an issue for IoT devices.  This is also an issue for message payloads
after the handshake completes.

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.

On a previous project I was trying to implement SSH for Arduino devices,
which requires support for a minimum packet size of 35000 bytes.  The best
I could do was implement a streaming mechanism to decrypt the packet on the
fly, consume the plaintext, and check the MAC later.  It is of course
really dumb to use data which hasn't been authenticated yet, which is why I
stopped work on SSH.  It just can't work in a RAM-constrained environment.

Long story short: we should probably define a maximum protocol name size
(128? 256? something like that), and provide some mechanism in the TLS
replacement to negotiate a maximum message payload size so that IoT
receivers can force the other end to chop the session data up into smaller
pieces.  If the sender exceeds the negotiated maximum, the receiver aborts
the connection.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170204/25be93d9/attachment.html>