<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Apr 23, 2016 at 7:40 AM, 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">If your protocol cares about having the other side affirmatively close<br>
the connection, then you can send a message saying "QUIT" or "close"<br>
or whatever.<br></blockquote><div><br></div><div>TCP is a transport layer with a defined start, data transfer phase, and end to a session.  Applications then run on top of that.<br><br>The Noise protocol sort of "is" our TCP.  It has a defined start (handshake) and data transfer phase, but no currently recommended way to end the data transfer phase except "the app does it through unspecified means".<br><br></div><div></div><div>We have packet types 0 and 1 with defined meanings for XXfallback.  Maybe we need a packet type 2 for "will no longer send data in this direction"?  The packet content is the output of EncryptWithAd() for the final nonce value, ad, and payload.  When a type 2 packet is received, the receiver will authenticate it, flag the direction as properly terminated, and then any further traffic will raise an error.  Maybe add EncryptFinalWithAd() and DecryptFinalWithAd() functions to CipherState to formalize it?<br><br>It is necessary for applications to get the details right.  For
 example, the packet type (0, 1, or 2) for all packets must be included 
in the "ad" to prevent MITM spoofing of an early session end by modifying the packet type on an earlier packet.<br><div></div><br></div><div>This may merely be a recommendation rather than a hard requirement.  "If the application doesn't already have its own mechanism to terminate, then here's one safe method that can be used".<br></div></div><br>Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div>