[noise] Transport protocol spec finalizing

[Trevor Perrin]

On Wed, Jul 12, 2017 at 5:28 PM, Alexey Ermishkin <scratch.net at gmail.com> wrote:
>
> 2) Yes, we reduce the noise_message length, but we also set the upper bound on the buffer size needed to process any of the incoming packets which seems like a good value to me.
> Otherwise it can grow up to 65535*2 + 8 bytes. Which is probably not so good for high loads and IoT guys.

I can believe some recipients will need an upper bound on the buffer
size, but this bound could be different values.  So it seems like
applications will need to be aware of this bound, and send initial
handshake messages small enough to be processed by all recipients
(<8K, <32K, <100K, whatever).

Given this, fixing the maximum ClientHello and ServerAuth packet
length to 64K, rather than allowing 64K apiece for noise_message and
negotiation_data, seems restrictive more than helpful.

It also complicates the calculations, since there's now a tradeoff
between negotiation_data and noise_message length.  For example, you
might want create the Noise message before filling in
negotiation_data, which is easier if the Noise message has a fixed
amount of space it can use, more complicated if the maximum Noise
message space depends on the negotiation_data, and vice versa.

So I'm not really seeing the advantages of putting length first?


> This can further be expanded to the second packet using the version field (or any other technique) which we'll have to do anyway if we exceed the 65k limit with post-quantum keys or long certificate chains

That could happen, but I'm hoping to avoid it - PQ lattice algorithms
are using keys of a few KB, and certificate chains usually have a few
certs of a few KB (max), as well.


Trevor