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

[Igor Solovyov]

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
have.
I didn't study current Noise spec scrupulously, so may be it's already
there.


>
> 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"
flag.
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.

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