[noise] expected length of messages during handshake

[David Wong]

> 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.

It might be that I bathed in TLS for too long, but application refers
to me as the application layer ton top of Noise.
Here we're saying that Noise itself needs to have framing, so this is
the secure layer.


>
> 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.
>

I'd say the use cases where you already have a framing for Noise are
small enough for us to add a relevant overhead of 2 bytes per messages
in the spec.
I think a more clever approach would be to have the possibility to
remove the 2-byte header in "advanced usages" for such scenarios.

>
> 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

Suggestion: protocol naming should be (temporarily?) changed to
include the draft version. This is what TLS 1.3 does, every draft
version changes the version to facilitate interoperability testings.
At least until a stable version of Noise gets released.

>  * Some way to pad ciphertexts to a fixed length
>  * An API based on streaming data instead of individual messages

Both of these should be taken care of if we prepend a 2-byte length
field to every Noise message.

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

Can't this just be done in the prologue?


> 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.
>

I agree with the sentiment, but I still feel like the 2-byte header is
important enough to be part of the core. I wouldn't imagine a TLS or a
Quick crypto without a length field. How good is a protocol if it
can't stand alone in its layer?

David