[noise] expected length of messages during handshake

[Trevor Perrin]

On Wed, Nov 1, 2017 at 10:39 PM, David Wong <davidwong.crypto at gmail.com> wrote:
>
>> "Length fields: Applications must handle any framing or additional
> length fields for Noise messages, considering that a Noise message may
> be up to 65535 bytes in length. If an explicit length field is needed,
> applications are recommended to add a 16-bit big-endian length field
> prior to each message."
>
> What really bugged me here on my first read is the word "Application"
> which should really be "your noise implementation". The application
> should not have to worry about framing of Noises messages. So I'll
> suggest a change of word here.

We're using the phrase "application" loosely in that spec I guess, but
I think it works well enough.  Not sure what better wording would be.


> In addition, when writing a Noise library, I expect it to be able to
> communicate to other libraries for interoperability testing. I cannot
> do that here.
>
> My question: why is this not part of the spec? (A 2 byte length-field
> is a minor addition.)

Like Justin said, it's possible to use Noise in ways where the length
is already known, so a length field would be redundant.

For example, maybe you have an efficient protocol for (smartcards,
IoT, message-passing, RPC, etc) where the parties exchange handshake
messages, and there's already framing to indicate message length.

Or maybe you're encoding Noise messages into individual files or
database fields, where length of the messages is already encoded.

Requiring this field to always be present would add 2 bytes of
unnecessary overhead, sometimes.


You raise a good point about interop.  If you want to use Noise
directly over, say, TCP, you will need length framing, and you might
need other things:
 * Some way to add type/version/negotiation data
 * Some way to pad ciphertexts to a fixed length
 * An API based on streaming data instead of individual messages

I think the right way to tackle these is as layer(s) built on top of
the Noise core.  NoiseSocket is a good step in that direction, IMO
[1].

I'd like to have another layer on top of that (maybe "NoiseLink"?)
that defines a negotiation language.  I'll write about that
separately.

Anyways, I think we agree that the Noise core spec is too low-level to
be useful for a lot of developers, who want something more
plug-and-play.

We should be trying to close that gap, but I think adding higher
layers like "NoiseSocket" is the way to do that, and we should be
switching focus to that while leaving the core alone.

Trevor

[1] http://noiseprotocol.org/specs/noisesocket.html