Re: [TLS] close_notify and TLS 1.3

[Hubert Kario <[e-mail]>]

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

Either you "MUST" act on received control messages or you do not.
If not, then the handling of errors by closing the read side (and NOT sending 
fatal alerts) should be specified.

Sending bad_record_mac while not replying to KeyUpdate seems very ugly to me; 
if the rest of the document is not updated in PR#1092.

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