Re: [TLS] close_notify and TLS 1.3

[David Schinazi <[e-mail]>]

Thanks for checking gents!

Would you like me to send a PR?

David


> On Nov 12, 2017, at 09:13, Eric Rescorla <[e-mail]> wrote:
> 
> Initial inspection suggests that NSS behaves the same way, so I would be fine with this change.
> 
> -Ekr
> 
> 
> On Sat, Nov 11, 2017 at 3:46 PM, David Benjamin <[e-mail] <mailto:[e-mail]>> wrote:
> I think this change is a good idea.
> 
> Our implementation actually does this already anyway. We are happy to continue servicing writes even when the read half has consumed a close_notify. I believe we inherited this behavior from OpenSSL, so it should be there too. Go's crypto/tls implementation appears to also already do this.
> 
> We don't have a particular need for the half-close semantics that I know of, but I don't care for the current spec text (it requires yet another undesirable read/write sync point). Aligning with TCP's semantics is also generally a good default.
> 
> On Sat, Nov 11, 2017 at 11:18 PM Martin Thomson <[e-mail] <mailto:[e-mail]>> wrote:
> 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 <[e-mail] <mailto:[e-mail]>> 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?
> >
> > Thanks,
> > David Schinazi
> >
> > _______________________________________________
> > TLS mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> >
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> _______________________________________________
> TLS mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls