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

[Eric Rescorla <[e-mail]>]

So 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)

We are currently preparing the 8446-bis, so I think the right place to have
this discussion is in that context.

-Ekr


On Mon, Aug 28, 2023 at 6:38 AM Ben Smyth <[e-mail]> wrote:

> 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
>>>
>>