[TLS] close_notify and TLS 1.3

[David Schinazi <[e-mail]>]

Hello all,

Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2 did.
I believe that has issues and this might be the right time to fix them.
The purpose of close_notify is to protect against data truncation attacks,
each side is required to send close_notify before closing the write side of
the transport connection so the other side knows that the data was not truncated.
As such, close_notify only needs half-close semantics to prevent truncation.

However, the specification contains the following text:
<< Each party MUST send a “close_notify” alert before closing the write side
    of the connection, unless some other fatal alert has been transmitted.
    The other party MUST respond with a “close_notify” alert of its own and close
    down the connection immediately, discarding any pending writes. >>

This means that an application-layer client can't send a query then close their
write transport when they know that they're done, because the server would
terminate the TLS session before sending the reply. On top of this, when
the server receives the close_notify, it may have already sent part of the reply
(or wrote it to the socket send buffer) so the responding close_notify would
in effect be inflicting a truncation attack on the client.

This doesn't make much difference for HTTP because clients already
don't close their write transport after sending a reply, however having the
option do do this could allow innovation in new protocols that can define
the semantics of when they use close_notify. An example is DNS PUSH:
https://tools.ietf.org/html/draft-ietf-dnssd-push <https://tools.ietf.org/html/draft-ietf-dnssd-push>

A proposal to solve this problem would be to give close_notify half-close
semantics: we keep the requirements that a close_notify be sent before
closing the transport, and that any data received after a close_notify is
ignored, but we simply remove the requirement to immediately reply
with a close_notify. This has the advantage that current implementations
are already compliant but future ones can leverage this improvement.

What do you think? Is this worth discussing on Thursday?

Thanks,
David Schinazi