I've sent out a PR: https://github.com/tlswg/tls13-spec/pull/1092 <https://github.com/tlswg/tls13-spec/pull/1092>
It might be a little verbose but I think it explains and solves the problem. Please let me know what you think! Thanks, David Schinazi > On Nov 12, 2017, at 09:47, Martin Thomson <martin.thom...@gmail.com> wrote: > > We suppress the sending of a close_notify if we have received one, but > that's a fairly simple thing to correct. > > On Sun, Nov 12, 2017 at 9:13 AM, 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
