[noise] NoiseSocket revision 1

Igor Solovyov igor.solovyov at gmail.com
Thu Aug 3 13:46:45 PDT 2017

Hi Trevor and all,

Thank you for reply.

On Thu, Aug 3, 2017 at 10:28 PM, Trevor Perrin <trevp at trevp.net> wrote:

> 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.
> 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.
I'd prefer to see device capabilities in a handshake message which IMHO
should be portable between all devices (regardless its size).

  * Q: Would we extend this flexibility to both transport *and*
> handshake messages?
I think it's better to leave handshake message small and portable as much
as possible.

> (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).
If in handshake message we can negotiate further transport message length
field size, then we can send what we want in subsequent messages.
Yes, it could make upper application level handshake a little bit slower,
but IMHO it's a reasonable price to make basic handshake message portable.

  * In NoiseSocket, we'd have various options:
>    - Make all length fields 32 bits?
Not flexible, but simple.

>    - Allow 32-bit length fields if explicitly requested (i.e.
> application calls a SetJumboLength(true) which affects all subsequent
> length fields, including padding?)
Do anybody need "Jambo"-padding? :)

>    - Allow 32-bit length fields only on transport messages, if
> explicitly requested? (SetJumboLengthTransport(true))?
I vote for this variant.

>  * Alternatively, we could just have 16-bit and 32-bit version of
> NoiseSocket?
It could lead double efforts for testing and support, I think.

>   * 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.
As for me it looks like overcomplication in comparison with some
capabilities passing over handshake message. But I could be wrong.

> There's a lot to think about here, including whether the optimization
> is worth the effort!
Good state:) Yeah, sometimes initial idea doesn't worth of efforts,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170803/87a187fe/attachment.html>

More information about the Noise mailing list