[noise] expected length of messages during handshake

[Justin Cormack]

On 1 November 2017 at 17:33, David Wong <davidwong.crypto at gmail.com> wrote:
>> The spec discusses length fields a bit, e.g. in "Application responsibilities":
>
> I think the two points I mention should not be delegated to the
> application's responsibility as these messages need to be processed
> via the ReadMessage function of Noise.
>
> For example, if an Noise encrypted ciphertext is fragmented into
> several messages, why would the application need to know about that or
> have to deal with that? The application should deal with the
> fragmentation of its own messages but not the of the layer underneath
> it.

It is assumed you have a transport layer underneath that ReadMessage
talks to.

> For the handshake phase, I think this makes even more sense as the
> application should have minimal impact there.
>
>> If an explicit length field is needed
>
> An explicit length field is always needed! unless you're confident
> your tcp messages are going to always arrive in one block (not
> fragmented) and never by blocks (appended to other noise messages).

You might not be using tcp. TCP usually needs a length, yes, although
you can also pad all the messages to fixed lengths instead. Other transports
already may include framing information.