Re: [TLS] close_notify and TLS 1.3

[Eric Rescorla <[e-mail]>]

On Mon, Nov 13, 2017 at 2:38 PM, Hubert Kario <[e-mail]> wrote:

> On Monday, 13 November 2017 13:25:07 CET Eric Rescorla wrote:
> > 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.
>
> how "MUST send a KeyUpdate of its own" is "you do nothing"?
>

You need to read to the end of the sentence
"prior to sending its next application data record". As no such record is
sent, you don't need to do anything.


> > 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.
>
> sending alerts after close_notify goes against the semantics of TCP half-
> close. If the intention is to support TCP half-close-like mechanism in
> TLS, we
> need to document when and where that abstraction is broken. In particular -
> that sending close_notify shouldn't be followed by closing the write side
> of
> the connection (be it TCP or Unix socket). Only that application_data
> packets
> are disallowed after close_notify.
>

As David says, this problem already exists.

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