Re: [TLS] [Technical Errata Reported] RFC8446 (7620)

[Eric Rescorla <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
>
> 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
>