<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Feb 4, 2017 at 8:33 AM, David Wong <span dir="ltr"><<a href="mailto:davidwong.crypto@gmail.com" target="_blank">davidwong.crypto@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> From the IETF/TLS experience, I'm pretty opposed to global number
registries.  It adds a lot of friction when everyone has to negotiate
with authorities to get their numbers assigned</span><div><div><br></div><div>this ^</div><div><br></div><div>This would hurt the simplicity of Noise so much. Strings are fine, and they make reading the code easily.</div></div></blockquote><div><br></div><div>I'm "Team String" as well  As Trevor points out, it is much easier for experimenters to pick a name and get going without waiting for the rubber stamp first. <br></div></div><br></div><div class="gmail_extra">Strings do have one drawback though - they are arbitrary-length which can be an issue for IoT devices.  This is also an issue for message payloads after the handshake completes.<br><br></div><div class="gmail_extra">I regularly work on embedded chips with RAM sizes of 8K, 20K, 48K, etc.  The maximum Noise packet payload is 65535 bytes.  When the IoT device is sending, this isn't an issue because it can pick a maximum size that is convenient for the device's RAM constraints.<br><br>On the receiving side it is a big issue if the sender can choose whatever length it likes.  Particularly for message payloads: the MAC must be checked before the data is used but the MAC may not arrive within the memory constraints of the receiver.<br><br>On a previous project I was trying to implement SSH for Arduino devices, which requires support for a minimum packet size of 35000 bytes.  The best I could do was implement a streaming mechanism to decrypt the packet on the fly, consume the plaintext, and check the MAC later.  It is of course really dumb to use data which hasn't been authenticated yet, which is why I stopped work on SSH.  It just can't work in a RAM-constrained environment.<br><br></div><div class="gmail_extra">Long story short: we should probably define a maximum protocol name size (128? 256? something like that), and provide some mechanism in the TLS replacement to negotiate a maximum message payload size so that IoT receivers can force the other end to chop the session data up into smaller pieces.  If the sender exceeds the negotiated maximum, the receiver aborts the connection.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>