[noise] Termination

[david wong]

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.

  

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.

  

Thanks for bearing with my questions :)

  

David

> On Apr 22 2016, at 4:40 pm, Trevor Perrin <trevp at trevp.net> wrote:  

>

> On Fri, Apr 22, 2016 at 1:15 PM, david wong
<davidwong.crypto at gmail.com> wrote:  
> There is little written about termination, in 12. Application  
> responsibilities:  
>  
>> Termination: Applications must consider that a sequence of Noise
transport  
>> messages could be truncated by an attacker. Applications should
include  
>> explicit length fields or termination signals inside of transport
payloads  
>> to signal the end of a stream of transport messages.  
>  
> and then in the following section:  
>  
>> Termination: Preventing attackers from truncating a stream of
transport  
>> messages is an application responsibility. See previous section.  
>  
> It sounds odd to me that the application running on top of Noise should
be  
> preoccupied by network attacks (such as termination here).

>

> Unless you're stuffing one application message into each Noise  
message, you could just think of Noise transport messages as giving  
you streams of data, like TCP.

>

> So you might need to add length fields or parseable structures, like  
any protocol on top of TCP.

>

> If your protocol cares about having the other side affirmatively close  
the connection, then you can send a message saying "QUIT" or "close"  
or whatever.

>

> Trevor

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160422/4b8fb315/attachment.html>