<head></head><body>OK, if I think of a common case of disconnection (not usually an attack, just a shitty internet connection), the application does have to deal with that, not the transport layer.<div><br></div><div>In the case of one message dropped in the middle of the communication, the nonce being out of order should produce a wrong MAC tag and the connection would terminate.<div><br></div><div>Thanks for bearing with my questions :)</div><div><br></div><div>David</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Apr 22 2016, at 4:40 pm, Trevor Perrin <trevp@trevp.net> wrote:
<br>
<p>On Fri, Apr 22, 2016 at 1:15 PM, david wong <davidwong.crypto@gmail.com> wrote:<br>> There is little written about termination, in 12. Application<br>> responsibilities:<br>><br>>> Termination: Applications must consider that a sequence of Noise transport<br>>> messages could be truncated by an attacker. Applications should include<br>>> explicit length fields or termination signals inside of transport payloads<br>>> to signal the end of a stream of transport messages.<br>><br>> and then in the following section:<br>><br>>> Termination: Preventing attackers from truncating a stream of transport<br>>> messages is an application responsibility. See previous section.<br>><br>> It sounds odd to me that the application running on top of Noise should be<br>> preoccupied by network attacks (such as termination here).</p>
<p>Unless you're stuffing one application message into each Noise<br>message, you could just think of Noise transport messages as giving<br>you streams of data, like TCP.</p>
<p>So you might need to add length fields or parseable structures, like<br>any protocol on top of TCP.</p>
<p>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.</p>
<p>Trevor</p>
</blockquote></body>