Re: [TLS] close_notify and TLS 1.3

[Hubert Kario <[e-mail]>]

On Saturday, 11 November 2017 10:21:11 CET David Schinazi 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
> <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?

what about alerts?

if you half-closed the connection for write and then received key-update, or 
message with an invalid tag, how are you supposed to react to it?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic