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

[Ben Smyth <[e-mail]>]

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