On Tue, Aug 29, 2023 at 1:56 AM Ben Smyth <resea...@bensmyth.com> wrote:
> 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. > I must be missing something, as I don't see how that would help. Perhaps you could provide an example of what it is you are concerned about? -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
