[noise] NoiseSocket revision 1

[Trevor Perrin]

On Thu, Aug 3, 2017 at 9:43 AM, Igor Solovyov <igor.solovyov at gmail.com> wrote:
>
> Sure, such workaround is possible. But I think the life could be much easier
> if Noise protocol permits to have "jumbo" messages by itself.
> I.e. less coding at application protocol level.


Hi Igor, all,

Good discussion about optimization and message size.  I don't know
much about this so I encourage people to keep discussing.

We previously discussed reducing max message size for IoT cases.  If
we add flexibility we could try to address both cases.  Some things to
consider:

 * In the core spec, we could change the 65535 limit to a default, and
allow sending larger messages if you are sure the recipient can handle
them.  This means the max message limits for sending and receiving
would be configurable and could be different (e.g. a small device
talking to a server might have a 4K limit for receiving, but a 2MB
limit for sending).  Libraries would have to change for this.

 * Q: Would we extend this flexibility to both transport *and*
handshake messages?

(The use of larger handshake messages might have an additional
motivation: Noise handshake messages have a single payload, and you
might want to send more than 64K of certificates or 0-RTT data in a
handshake message).

 * In NoiseSocket, we'd have various options:
   - Make all length fields 32 bits?
   - Allow 32-bit length fields if explicitly requested (i.e.
application calls a SetJumboLength(true) which affects all subsequent
length fields, including padding?)
   - Allow 32-bit length fields only on transport messages, if
explicitly requested? (SetJumboLengthTransport(true))?

 * Alternatively, we could just have 16-bit and 32-bit version of NoiseSocket?

 * We need to define protocol layer(s) on top of NoiseSocket that
actually do negotiation (i.e. advertise a list of Noise protocols in
protobufs or something).  So we could add the ability for each party
to send the maximum message size it can receive, if different than
65535.  If your peer advertises a limit > 65535 then you're required
to send transport and/or handshake messages with 32-bit length fields,
i.e. every implementer would be required to support this.

There's a lot to think about here, including whether the optimization
is worth the effort!

Trevor