On Tue, Aug 29, 2023 at 10:55:56AM +0200, Ben Smyth wrote:
> TLS 1.2 dictates: Either party may initiate a close by sending a
> close_notify alert...The other party MUST respond with a close_notify
> alert of its own and close down the connection immediately, discarding
> any pending writes.
>
> RFC 8446-bis could simply forbid that behaviour, e.g., This does not have
> any effect on the read side of the sender's connection; a party receiving a
> "close_notify" alert MUST NOT respond with a "close_notify" alert of its
> own. Note that this is a change from versions of TLS prior to TLS 1.3 in
> which receivers were required to react to a "close_notify" by discarding
> pending writes and sending an immediate "close_notify" alert of their own.
I think what's being said here is not "MUST NOT", but "need not". In
other words, TLS 1.3 supports (at least to some extent) half-closed TLS
connections, in which the side that did not send a "close_notify" can
attempt to continue to send data.
I don't think there's anything here to "forbid", rather the intent of
the present text could perhaps be more clearly expressed.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
