<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:2.0cm 42.5pt 2.0cm 3.0cm;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=RU link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>I think we can try strings with 1 byte prepending length and see how it goes.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>As for chopping data, in my POC<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><a href="https://github.com/go-noisetls/noisetls/blob/master/conn.go#L170">https://github.com/go-noisetls/noisetls/blob/master/conn.go#L170</a><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'>I used the same approach TLS uses. If I need to send N bytes, I ask my code how much can I send right now and split data into chunks. Each chunk is an encrypted noise transport message, so it’s implicitly authenticated with AEAD and has length field 2 bytes which cannot exceed 64k. So, high-level code treats everything like a stream, but each chunk is authenticated separately and you don’t need to extra MAC plaintext<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'> <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> Noise [mailto:noise-bounces@moderncrypto.org] <b>On Behalf Of </b>Rhys Weatherley<br><b>Sent:</b> Saturday, February 04, 2017 4:53 AM<br><b>To:</b> David Wong <davidwong.crypto@gmail.com><br><b>Cc:</b> noise <noise@moderncrypto.org><br><b>Subject:</b> Re: [noise] A simple and safe TLS/TCP-like protocol<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><div><div><p class=MsoNormal>On Sat, Feb 4, 2017 at 8:33 AM, David Wong <<a href="mailto:davidwong.crypto@gmail.com" target="_blank">davidwong.crypto@gmail.com</a>> wrote:<o:p></o:p></p><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm'><p class=MsoNormal>> 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<o:p></o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>this ^<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>This would hurt the simplicity of Noise so much. Strings are fine, and they make reading the code easily.<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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. <o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>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.<o:p></o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Cheers,<o:p></o:p></p></div><div><p class=MsoNormal style='margin-bottom:12.0pt'>Rhys.<o:p></o:p></p></div></div></div></body></html>