Re: [TLS] close_notify and TLS 1.3

This seems like it might be worth looking at.  This seems to be
something that harks back to SSL3 or even earlier.  We aren't going to
make it so that you can rely on this behaviour, but we might be able
to make it possible to half-close, which for new protocols using TLS
could be hugely useful.

On Sat, Nov 11, 2017 at 5:21 PM, David Schinazi <dschinazi@apple.com> wrote:
> 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
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>