[noise] NoiseSocket revision 1

[Igor Solovyov]

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,

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