On Tue, 29 Aug 2023, 14:31 Eric Rescorla, <e...@rtfm.com> wrote: > 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? >
Sure: As-is the specification doesn't mandate against the old behaviour; a specification compliant implementation may be vulnerable to the TLS 1.2 truncation attack arising from closure in both directions. Whilst I appreciate the issues raised in this thread, I believe the specification could be stricter by mandating against the old behaviour. As-is, hints are raised, guidance given, but there's no strict requirement. Perhaps I'm just reading too rigorously, there's no need to formally forbid---as an IETF outsider, that seems a little lax, I'd expect a change from two-way closure to one-way closure to be mandated, thereby explicitly teaching away from a known vulnerability. RFC8446-bis is an opportunity to polish the original spec. >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
