[noise] Termination

[Trevor Perrin]

On Fri, Apr 22, 2016 at 3:08 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Sat, Apr 23, 2016 at 7:40 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> 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.
>
>
> TCP is a transport layer with a defined start, data transfer phase, and end
> to a session.  Applications then run on top of that.
>
> 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".


We discussed termination a bunch last year, and decided to leave this
to application layer [1].  Some reasons:

"""
 * The application layer is in the best position to know what sort of
termination it needs (length field, terminator byte, other).

 * Providing an API for this in the crypto layer doesn't guarantee the
application will use it correctly, so we're dependent on the
application in any case, we might as well let the application handle
the whole thing.
"""

Also, I think the TLS experience with close_notify shows that having
this in the crypto layer is more confusing than useful.  It creates 3
ways the end of a session could be signalled (TCP close, TLS
close_notify, or within the application).  TLS clients are supposed to
respond to close_notify with their own close_notify, so there's a
little "session closed" handshake, and if this isn't done correctly
then resumption is supposed to be disallowed, but in practice a lot of
applications close things sloppily so I think these rules have to be
ignored, and it's kind of a vestigial feature.

So anyways, I like that the current design keeps it simple...


> 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?
>
> 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.

Just to be clear, the type fields for Noise Pipes are just a
suggestion, they're not mandatory - however you indicate the different
paths would work (and if you use types for Noise Pipes, they don't
need to be bound as prologue / associated data).

Trevor

[1]
https://moderncrypto.org/mail-archive/noise/2015/000238.html
https://moderncrypto.org/mail-archive/noise/2015/000244.html