Subject: Re: [TLS] [Editorial Errata Reported] RFC8446 (6820)

From: Chris Smiley <[email-masked]>
Date: Wed, 9 Feb 2022 14:50:38 -0800

Greetings,

We are unable to verify this erratum that the submitter marked as editorial.  
Please note that we have changed the “Type” of the following errata 
report to “Technical”.  As Stream Approver, please review and set the 
Status and Type accordingly (see the definitions at 
https://www.rfc-editor.org/errata-definitions/).

You may review the report at: 
https://www.rfc-editor.org/errata/eid6820

Please see https://www.rfc-editor.org/how-to-verify/ for further 
information on how to verify errata reports.

Further information on errata can be found at: 
https://www.rfc-editor.org/errata.php.

Thank you.

RFC Editor/cs

> On Jan 21, 2022, at 5:14 AM, RFC Errata System <[email-masked]> 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/eid6820
> 
> --------------------------------------
> Type: Editorial
> Reported by: Leander Schwarz <[email-masked]>
> 
> Section: 6.2
> 
> Original Text
> -------------
> unsupported_extension:  Sent by endpoints receiving any handshake
>      message containing an extension known to be prohibited for
>      inclusion in the given handshake message, or including any
>      extensions in a ServerHello or Certificate not first offered in
>      the corresponding ClientHello or CertificateRequest. 
> 
> Corrected Text
> --------------
> unsupported_extension:  Sent by endpoints receiving any handshake
>      message containing an extension in a ServerHello or Certificate
>      not first offered in the corresponding ClientHello or 
>      CertificateRequest.
> 
> Notes
> -----
> The definition of the unsupported_extension alert in section 6.2 contradicts the statements in section 4.2:
> 
>        If an implementation receives an extension
>        which it recognizes and which is not specified for the message in
>        which it appears, it MUST abort the handshake with an
>   "illegal_parameter" alert.
> 
> While this might not be inconsistent due to the "abort the handshake with an X alert" specification at the beginning of section 6.2, it might lead to confusion. (see https://mailarchive.ietf.org/arch/msg/tls/hGOGWZRMg718mWqOZ06LwjV9360/).
> 
> 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
>