[noise] expected length of messages during handshake

[Trevor Perrin]

On Thu, Nov 2, 2017 at 11:17 AM, David Wong <davidwong.crypto at gmail.com> wrote:
>> 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.

We're using the term "application" here to mean the entire context
Noise is used within, not just the payloads.

It's possible we could be clearer about that.  Happy to consider
suggestions (small edits are better than major rewording, at this
point).


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

That ends up at the same place, doesn't it?  We either say:
 * This isn't part of the Noise message but you can optionally add it, or
 * This is part of the Noise message but you can optionally remove it

The first option seems better because it doesn't create ambiguity
about what is the Noise message and what isn't.

It also matches how we've explained this for years.  We shouldn't
change things like this without a strong reason, IMO.



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

We haven't broken compatibility of any named protocol since mid-2015,
I think (the new PSK handling uses a different naming scheme).

We have a bunch of libraries and some users, and have an informal
commitment to not breaking them, so it's already pretty stable.

The TLS case is different:  There are multiple implementations of
incompatible TLS 1.3 drafts in the wild, so they have a system to
negotiate which draft they support [1].  That's not a problem we have.


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

No, the padding of ciphertexts needs an additional length field inside
the encrypted payload - see NoiseSocket for details.


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

The prologue is part of it, but to save round-trips you don't want to
perform negotiation separately from sending Noise messages, you want
to weave them together to some extent.  I.e. the client offers an
initial ephemeral in its first message while advertising its cipher
options, for example.

See NoiseSocket for more discussion.


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

I think the Noise core spec is more of a toolkit for building things
like TLS and QUIC, rather than directly comparable to TLS or QUIC.

I agree we should have more "plug-and-play" options for easily
deploying Noise over TCP, but I think the way to tackle that is going
to be outside the Noise core spec, in things like NoiseSocket.


Trevor

[1] https://github.com/tlswg/tls13-spec/wiki/Implementations