Re: [TLS] close_notify and TLS 1.3

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario <[e-mail]> wrote:

> 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,


I assume you mean with update_requested set. in any case, you do nothing:

If the request_update field is set to "update_requested" then the receiver
MUST
send a KeyUpdate of its own with request_update set to
"update_not_requested" prior
to sending its next application data record.



> or
> message with an invalid tag, how are you supposed to react to it?
>

I think it would be fine to either silently tear down the connection or to
send an alert.

-Ekr


>
> --
> 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
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>