<div dir="ltr">Hi Trevor,<br><br><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 4, 2017 at 7:53 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
>> - Allow 32-bit length fields if explicitly requested (i.e.<br>
>> application calls a SetJumboLength(true) which affects all subsequent<br>
>> length fields, including padding?)<br>
><br>
> Do anybody need "Jambo"-padding? :)<br>
<br>
The goal of padding is to hide the real length, so we should probably<br>
keep the ability to pad a message any amount (i.e. a 2 MB transport<br>
message could hold 2 MB of padding).<br></blockquote><div><br></div><div>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].<br></div><div>If it's not satisfactory(?), then sure, 32-bit have to be used.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>To be more clear, I'll sketch a negotiation protocol that uses<br>
NoiseSocket to negotiate both the Noise protocol and also a<br>
max_transport_size.<br>
<br>
We've tried to avoid negotiation to keep runtime behavior simple. So<br>
even if we support larger transport messages, it's an open question<br>
whether we should negotiate this versus just having endpoints<br>
configured for it.<br></blockquote><div><br></div><div>Agree. In such case some kind of clear error signaling is desirable.<br>One endpoint could be configured to use 16-bit length, another one to use 32-bit by mistake.<br></div><div>After one tried to connect to other some clear error code would be nice to have.<br></div><div>I didn't study current Noise spec scrupulously, so may be it's already there.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
But it's useful to see what negotiation would look like.<br>
<br>
Anyways, the idea is:<br>
<br>
* This is a JSON example, but could be translated to protobufs, XML, etc.<br></blockquote><div> <br></div><div>Thanks, the example is super-clear and such approach works as for me.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* The initiator sends max_transport_size if it wants a different size<br>
than 65535. The responder either explicitly accepts this size or<br>
sends a smaller size.<br>
<br>
* If a value > 65535 is agreed on, then transport messages use<br>
"jumbo" length fields, i.e. noise_message_len and body_len are 32 bits<br>
instead of 16 bits.<br></blockquote><div><br></div><div>What if we use simpler approach: do negotiation of either 16-bit or 32-bit length for both directions, but not some concrete value?<br></div><div>Something like such simple rules:<br></div><div>1. Client send handshake with a capability field which contains dedicated flag for "32-bit message length".<br></div><div>2. Server answers with own capability providing its "32-bit message length" flag.<br></div><div>3 Both side MUST use the min(16, 32)-bit length based on both flags. Or drop connection if it's inappropriate.<br></div><div><br></div><div>What do you think?<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">However, maybe it's<br>
simpler just to negotiate a single value here, instead of having<br>
separate send / receive values?<span class="gmail-HOEnZb"><font color="#888888"><br></font></span></blockquote><div><br></div><div>Yes, please see my proposition above. <br></div><div><br></div><div>Regards,<br></div><div>Igor. <br></div></div><br></div></div></div>