RFC 8446, "The Transport Layer Security (TLS) Protocol Version 1.3", August 2018

Errata ID: 7620
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Ben Smyth
Date Reported: 2023-08-28

Section 6.1 says:

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.

It should say:

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.

Report New Errata