On Mon, 28 Aug 2023, Eric Rescorla, wrote: > ...there are quite a few situations in which endpoints close the >>> connection before receiving a close_notify, for instance, when they receive >>> an end of data message in the application protocol or when they time out. >>> The former case is generally safe, the latter is not, but extremely >>> common, in fact perhaps the dominant case....I'm not sure this is an >>> erratum as I think it correctly describes the situation and it's a >>> judgement call whether we ought to have a requirement here or whether it's >>> a 6919 MUST (BUT WE KNOW YOU WON'T) >>> >> 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.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
