<div dir="ltr"><div>Hi Trevor and all,<br><br></div>Thank you for reply.<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 3, 2017 at 10:28 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"><span class="gmail-">On Thu, Aug 3, 2017 at 9:43 AM, Igor Solovyov <<a href="mailto:igor.solovyov@gmail.com">igor.solovyov@gmail.com</a>> wrote:<br>
><br>
> Sure, such workaround is possible. But I think the life could be much easier<br>
> if Noise protocol permits to have "jumbo" messages by itself.<br>
> I.e. less coding at application protocol level.<br>
<br>
<br></span>Some things to<br>
consider:<br>
<br>
 * In the core spec, we could change the 65535 limit to a default, and<br>
allow sending larger messages if you are sure the recipient can handle<br>
them.  This means the max message limits for sending and receiving<br>
would be configurable and could be different (e.g. a small device<br>
talking to a server might have a 4K limit for receiving, but a 2MB<br>
limit for sending).  Libraries would have to change for this.<br></blockquote><div>I'd prefer to see device capabilities in a handshake message which IMHO should be portable between all devices (regardless its size).<br></div><div><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"> 
* Q: Would we extend this flexibility to both transport *and*<br>
handshake messages?<br></blockquote><div>I think it's better to leave handshake message small and portable as much as possible.<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">
(The use of larger handshake messages might have an additional<br>
motivation: Noise handshake messages have a single payload, and you<br>
might want to send more than 64K of certificates or 0-RTT data in a<br>
handshake message).<br></blockquote><div>If in handshake message we can negotiate further transport message length field size, then we can send what we want in subsequent messages.<br></div><div>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.<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"> 
* In NoiseSocket, we'd have various options:<br>
   - Make all length fields 32 bits?<br></blockquote><div>Not flexible, but simple.<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">
   - 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></blockquote><div>Do anybody need "Jambo"-padding? :)<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">
   - Allow 32-bit length fields only on transport messages, if<br>
explicitly requested? (SetJumboLengthTransport(true)<wbr>)?<br></blockquote><div>I vote for this variant.<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>
 * Alternatively, we could just have 16-bit and 32-bit version of NoiseSocket?<br></blockquote><div>It could lead double efforts for testing and support, I think.<br><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"> 
* We need to define protocol layer(s) on top of NoiseSocket that<br>
actually do negotiation (i.e. advertise a list of Noise protocols in<br>
protobufs or something).  So we could add the ability for each party<br>
to send the maximum message size it can receive, if different than<br>
65535.  If your peer advertises a limit > 65535 then you're required<br>
to send transport and/or handshake messages with 32-bit length fields,<br>
i.e. every implementer would be required to support this.<br></blockquote><div>As for me it looks like overcomplication in comparison with some capabilities passing over handshake message. But I could be wrong.<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>
There's a lot to think about here, including whether the optimization<br>
is worth the effort!<br></blockquote>Good state:) Yeah, sometimes initial idea doesn't worth of efforts,<br><br></div><div class="gmail_quote">Regards,<br></div><div class="gmail_quote">Igor.<br></div><div class="gmail_quote"><br><br></div></div></div></div></div></div>