Re: [TLS] close_notify and TLS 1.3

[David Schinazi <[e-mail]>]

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 <[e-mail]> 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-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