Please. -Ekr
On Sat, Nov 11, 2017 at 5:24 PM, David Schinazi <dschin...@apple.com> wrote: > Thanks for checking gents! > > Would you like me to send a PR? > > David > > > On Nov 12, 2017, at 09:13, Eric Rescorla <e...@rtfm.com> 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 <david...@chromium.org> > 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 <martin.thom...@gmail.com> >> 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 <dschin...@apple.com> >>> 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 >>> > >>> > 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 >>> > TLS@ietf.org >>> > https://www.ietf.org/mailman/listinfo/tls >>> > >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
