Re: [TLS] close_notify and TLS 1.3

[Eric Rescorla <[e-mail]>]

Please.

-Ekr


On Sat, Nov 11, 2017 at 5:24 PM, David Schinazi <[e-mail]> wrote:

> 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]>
> 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]>
>> 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]>
>>> 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
>>> > [e-mail]
>>> > https://www.ietf.org/mailman/listinfo/tls
>>> >
>>>
>>> _______________________________________________
>>> TLS mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>
>