Re: [TLS] close_notify and TLS 1.3

[David Benjamin <[e-mail]>]

On Mon, Nov 13, 2017 at 8:25 PM Eric Rescorla <[e-mail]> wrote:

> On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario <[e-mail]> wrote:
>
>> On Saturday, 11 November 2017 10:21:11 CET David Schinazi 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?
>>
>> what about alerts?
>
>
>> if you half-closed the connection for write and then received key-update,
>
>
> I assume you mean with update_requested set. in any case, you do nothing:
>
> If the request_update field is set to "update_requested" then the receiver
> MUST
> send a KeyUpdate of its own with request_update set to
> "update_not_requested" prior
> to sending its next application data record.
>
>
>
>> or
>> message with an invalid tag, how are you supposed to react to it?
>>
>
> I think it would be fine to either silently tear down the connection or to
> send an alert.
>

The latter seems better to me. The peer isn't going to parse it anyway,
since it was preceded by a closure alert, and it keeps the invariant that
one does not send anything after a closure alert.

But this problem isn't caused by this proposal and exists regardless. The
proposal is about whether the party which closes *second* must *send* a
close_notify after *receiving* one. This problem is if the party which
closes *first* *receives* garbage after *sending* a close_notify and
waiting for the corresponding one. That case is unavoidable so long as
waiting for the peer's close_notify after sending one is a supported
operation. The peer may send garbage.

David