On Mon, 15 Mar 2021 at 11:52, Jeremy Harris <j...@wizmail.org> wrote:
> 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?
>
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.
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?
>
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.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
