[noise] Negotiating transport message size (was: Re: NoiseSocket revision 1)
igor.solovyov at gmail.com
Fri Aug 4 11:10:51 PDT 2017
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
> 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...
More information about the Noise