[noise] expected length of messages during handshake

[David Wong]

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

I see, this makes it harder to have Noise as a pure library to be used
as a secure layer in between the application and the transport.
My implementation can be used exactly like you use TLS in Go (cf.
https://github.com/mimoo/NoiseGo/tree/master/readable )
This means that the use of Noise vs TLS is completely transparent to
the application on top. The same interfaces are used and for the
application it just looks like you're reading and writing from
sockets.

IMO it would be clearer if Noise defined application as the thing
running on top of Noise, and "protocol implementation" as the
implementation of Noise.


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

Totally! I guess my point is that I'm arguing for option 1 because:

* it makes Noise work without a framing protocol underneath it
* it makes any implementation of Noise interoperable without something
like NoiseSocket

about ambiguity, you could keep Noise messages and have a 2-byte
length header + Noise message = Noise frame
or find something along the lines. TLS does it with way more layers
and it's not too bad

ex:

TLSRecord > TLSPlaintext > handshakeMessage > ...

or

TLSRecord > TLSCiphertext > TLSInnerPlaintext > handshakeMessage > ...

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

Agree. That's the tricky part, in my opinion it's a strong reason but
I'll let you decide.

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

Ah you meant a length-hiding padding. There are arguments that this
could be delegated to the application itself. I don't feel like it's
an urgent issue personally.

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

I think I understand what you're saying.

Thinking about adoption: having libraries in different languages is
probably one of the top priority for Noise. If tomorrow someone wants
to be able to have some of his device run Noise in C to communicate
with his/her servers in Go, then he/she should be able to just pick up
libraries in both languages and have them communicate seamlessly. Are
you saying that people should focus their effort on publishing open
source libraries for things like Noise Socket instead? This would make
my library obsolete :> I guess I'll have to look at Noise Socket.

David