Yes, we agree. I anticipate necessity to reduce the strength my wording (or to ignore). I raise this errata only to discuss specification-compliant implementations being vulnerable to truncation attack; it'd surely be better to have a SHOULD or SHOULD NOT.
On Mon, 28 Aug 2023, 14:43 Eric Rescorla, <e...@rtfm.com> wrote: > Hi Ben, > > Before addressing the text, let's make sure we are on the same page about > the situation. > > As you probably know, 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. Do we agree on that? > > -Ekr > > > On Mon, Aug 28, 2023 at 4:02 AM RFC Errata System < > rfc-edi...@rfc-editor.org> wrote: > >> The following errata report has been submitted for RFC8446, >> "The Transport Layer Security (TLS) Protocol Version 1.3". >> >> -------------------------------------- >> You may review the report below and at: >> https://www.rfc-editor.org/errata/eid7620 >> >> -------------------------------------- >> Type: Technical >> Reported by: Ben Smyth <resea...@bensmyth.com> >> >> Section: 6.1 >> >> Original Text >> ------------- >> Each party MUST send a "close_notify" alert before closing its write >> side of the connection, unless it has already sent some error alert. >> This does not have any effect on its read side of the connection. >> Note that this is a change from versions of TLS prior to TLS 1.3 in >> which implementations were required to react to a "close_notify" by >> discarding pending writes and sending an immediate "close_notify" >> alert of their own. That previous requirement could cause truncation >> in the read side. Both parties need not wait to receive a >> "close_notify" alert before closing their read side of the >> connection, though doing so would introduce the possibility of >> truncation. >> >> Corrected Text >> -------------- >> Each party MUST send a "close_notify" alert before closing its write >> side of the connection, unless it has already sent some error alert. >> This SHOULD NOT have any effect on the read side of the sender's >> connection; >> parties SHOULD receive a "close_notify" alert before closing the read >> side of their connection. >> 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. That previous requirement could cause truncation >> in the read side. Both parties need not wait to receive a >> "close_notify" alert before closing their read side of the >> connection, though doing so would introduce the possibility of >> truncation. >> >> Notes >> ----- >> As-is there's a specification-level vulnerability: >> Specification-compliant implementations may be vulnerable to truncation >> attacks. >> >> I suggest using SHOULD NOT & SHOULD for better signposting and to avoid >> specification-level vulnerability. >> >> I also suggest minor tweaks for readability. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC8446 (draft-ietf-tls-tls13-28) >> -------------------------------------- >> Title : The Transport Layer Security (TLS) Protocol Version >> 1.3 >> Publication Date : August 2018 >> Author(s) : E. Rescorla >> Category : PROPOSED STANDARD >> Source : Transport Layer Security >> Area : Security >> Stream : IETF >> Verifying Party : IESG >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
