[noise] Negotiating transport message size (was: Re: NoiseSocket revision 1)

Igor Solovyov igor.solovyov at gmail.com
Fri Aug 4 11:10:51 PDT 2017

Hi Trevor,

On Fri, Aug 4, 2017 at 7:53 PM, Trevor Perrin <trevp at trevp.net> wrote:

> >>    - 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? :)
> The goal of padding is to hide the real length, so we should probably
> keep the ability to pad a message any amount (i.e. a 2 MB transport
> message could hold 2 MB of padding).

I see. I mean if we leave padding size as 16-bit field we also can hide
real length, but in diapason [real_data_size .. real_data_size+64KiB].
If it's not satisfactory(?), then sure, 32-bit have to be used.

> To be more clear, I'll sketch a negotiation protocol that uses
> NoiseSocket to negotiate both the Noise protocol and also a
> max_transport_size.
> We've tried to avoid negotiation to keep runtime behavior simple.  So
> even if we support larger transport messages, it's an open question
> whether we should negotiate this versus just having endpoints
> configured for it.

Agree. In such case some kind of clear error signaling is desirable.
One endpoint could be configured to use 16-bit length, another one to use
32-bit by mistake.
After one tried to connect to other some clear error code would be nice to
I didn't study current Noise spec scrupulously, so may be it's already

> But it's useful to see what negotiation would look like.
> Anyways, the idea is:
>  * This is a JSON example, but could be translated to protobufs, XML, etc.

Thanks, the example is super-clear and such approach works as for me.

>  * The initiator sends max_transport_size if it wants a different size
> than 65535.  The responder either explicitly accepts this size or
> sends a smaller size.
>  * If a value > 65535 is agreed on, then transport messages use
> "jumbo" length fields, i.e. noise_message_len and body_len are 32 bits
> instead of 16 bits.

What if we use simpler approach: do negotiation of either 16-bit or 32-bit
length for both directions, but not some concrete value?
Something like such simple rules:
1. Client send handshake with a capability field which contains dedicated
flag for "32-bit message length".
2. Server answers with own capability providing its "32-bit message length"
3 Both side MUST use the min(16, 32)-bit length based on both flags. Or
drop connection if it's inappropriate.

What do you think?

> However, maybe it's
> simpler just to negotiate a single value here, instead of having
> separate send / receive values?

Yes, please see my proposition above.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20170804/5baa0b99/attachment.html>

More information about the Noise mailing list