Subject: [TLS] TLS1.3 clarification request

From: Jeremy Harris <[email-masked]>
Date: Mon, 15 Mar 2021 10:52:49 +0000

Hi,

Could people please confirm a detail of TLS 1.3 session
close behaviour?  Specifically, are half-closes supported
in similar fashion to TCP half-closes - in that it is
legitimate for one end to issue a Close Notify alert
and for the other end to receive that alert but continue
to transmit data after such reception and before sending
its own Close Notify?

Further, is it reasonable for the above first end to
expect the above second end to continue processing and
sending data that would have been sent in the absence of
such a first Close Alert?

I ask because of the observed actions of Google MTA servers.
When using a TLS1.3 connection, after STARTTLS on an ESMTP
connection with PIPELINING and CHUNKING - if the smtp client
pipelines a full set of MAIL, RCPT, BDAT nnnn LAST, QUIT
*and* follows those with a TLS Close Notify then the Google
server issues an immediate TCP FIN.  It does this without
sending any SMTP responses (even for the MAIL command)
and it does not send a TLS Alert of any kind.

If the full ESMTP sequence give is sent without the TLS
Close Notify, then SMTP responses are transmitted by the
SMTP server as expected.
-- 
Cheers,
   Jeremy

PS: I am aware that TLS1.2 does not support half-closes.

---

From: Ben Smyth <[email-masked]>
Date: Tue, 16 Mar 2021 08:53:27 +0100

> to transmit data after such reception and before sending

This seems like expected behaviour: An endpoint has finished using an
outbound connection and raises alert close_notify (Section 6.1):

    This alert notifies the recipient that the sender will not send any
more messages on this connection. Any data received after a closure alert
has been received MUST be ignored.

The text goes one:

    This [close_notify alert] does not have any effect on its read side of
the connection.

The endpoint may continue receiving on an inbound connection.

> such a first Close Alert?

The endpoint should expect their interlocutor to ignore any data received
after the alert: Any data received after a closure alert has been received
MUST be ignored.

The endpoint should expect any data sent before raising alert close_notify
to be delivered: It is assumed that closing the write side of a connection
reliably delivers pending data before destroying the transport.

Whether an interlocutor processes data sent before alert close_notify is
seemingly not governed by the specification, which seems reasonable.

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 16 Mar 2021 19:03:09 +0000

> seemingly not governed by the specification, which seems reasonable.

So, that doesn't directly answer that portion of my question - but
does appear to make a half-close useless, by requiring an end
to hold off sending a Close alert until after if has received all
data that the far end is expected to send.

Do I understand that right?  And if so, what is the point of the
language in the RFC that appears to permit a half-close?
-- 
Thanks,
   Jeremy

---

From: Ben Smyth <[email-masked]>
Date: Wed, 17 Mar 2021 08:15:53 +0100

> language in the RFC that appears to permit a half-close?

Specifications don't define systems, they guide design. The specification
does not "requir[e] an end to hold off sending a Close alert until after if
has received all data that the far end is expected to send," the
specification merely allows such behaviour. Perhaps one scenario where that
behaviour is useful: An endpoint is about to be comprimised and raises an
alert to avoid secrets being leaked.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 17 Mar 2021 10:10:44 -0400

> alert to avoid secrets being leaked.

FWIW, I largely part ways with Ben's assessment, and particularly the
strawman scenario above.  TLS 1.3 does in fact make it possible to
support half-close in mutually cooperative applications, and there
is no expectation that a close-notify on one side must immediately
be accompanied by a similar action on the other, the other side
can continue to send applicatoin data traffic.

However, what I don't read into 8446 is an obligation or expectation
that applications will routinely support half close.  Some probably
should (e.g. an HTTPS server should probably continue with its response
even after a half-close on the client-side following the request).

However, if applications don't support half-close, and fail to respond
to prior requests upon receipt of close-notify, I don't think they're
violating the specification, they're merely not half-close compatible.

If some application protocol is expected to support half-close, that
should be specified in some relevant application-specific standard.

-- 
    Viktor.

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 17 Mar 2021 14:31:19 +0000

On 17/03/2021 07:15, Ben Smyth wrote:
> Perhaps one scenario where that

I'd have tout that a section 6.2 Error Alert would be more
appropriate in such a situation, than the (implicitly
non-error) section 6.1 Closure Alert I'm discussing.

Do you at least agree that Google is in violation of the 6.1
wording requiring that it sends a Close Alert before sending
a TCP FIN?
-- 
Cheers,
   Jeremy

---

From: Ben Smyth <[email-masked]>
Date: Wed, 17 Mar 2021 15:45:53 +0100

> wording requiring that it sends a Close Alert before sending

Which aspect of Section 6.1 do you think Google doesn't comply with?

---

From: Jeremy Harris <[email-masked]>
Date: Wed, 17 Mar 2021 15:00:07 +0000

> Which aspect of Section 6.1 do you think Google doesn't comply with?

"Each party MUST send a "close_notify" alert before closing its write
    side of the connection, unless it has already sent some error alert."

-- 
Cheers,
   Jeremy