Upon reflection, I think Daniel has a point about the text, as the description of "unsupported_extension" (as opposed to the name) seems to cover this case. With that said, I don't really think it's helpful to try to change the alert at this point, as it will just lead to confusion, especially given the liminal state of errata. For this reason, I don't think Verified is appropriate. Perhaps HDFU, as the WG could consider it then? HDFU doesn't seem to necessarily indicate that we agree with it.
-Ekr On Thu, Jun 11, 2026 at 4:00 AM Deb Cooley <[email protected]> wrote: > Thanks, I'll reject the errata next time I'm in that system (reported to > be easier now). > > Deb > > On Wed, Jun 10, 2026 at 5:35 PM David Schinazi <[email protected]> > wrote: > >> I agree with EKR. Any TLS stack that implements this MUST does, by >> definition, support this extension. >> David >> >> On Wed, Jun 10, 2026 at 11:23 AM Eric Rescorla <[email protected]> wrote: >> >>> I don't think this is correct. The extension *is* supported, it's just >>> not permitted. >>> >>> On Wed, Jun 10, 2026 at 11:18 AM <[email protected]> wrote: >>> >>>> The following errata report has been submitted for RFC9149, >>>> "TLS Ticket Requests" >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> https://errata.rfc-editor.org/eid8996/ >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Daniel McCarney <[email protected]> >>>> >>>> Section 3 says: >>>> >>>> Original Text >>>> ------------- >>>> Servers MUST NOT send the "ticket_request" extension in any handshake >>>> message, including ServerHello or HelloRetryRequest messages. A client MUST >>>> abort the connection with an "illegal_parameter" alert if the >>>> "ticket_request" extension is present in any server handshake message. >>>> >>>> Corrected Text >>>> -------------- >>>> Servers MUST NOT send the "ticket_request" extension in any handshake >>>> message, including ServerHello or HelloRetryRequest messages. A client MUST >>>> abort the connection with an "unsupported_extension" alert if the >>>> "ticket_request" extension is present in any server handshake message. >>>> >>>> Notes >>>> ----- >>>> RFC 8446 defines the illegal_parameter alert as used when "A field in >>>> the handshake was incorrect or inconsistent with other fields. This alert >>>> is used for errors which conform to the formal protocol syntax but are >>>> otherwise incorrect.", and the unsupported_extension alert as "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.". >>>> >>>> The unsupported_extension alert seems like a direct mapping to the >>>> condition described in Section 3 of RFC 9149: the client endpoint received >>>> a handshake message containing an extension that's known to be prohibited >>>> for inclusion in the given handshake message. In contrast it's harder to >>>> draw a straight-line justification for using illegal_parameter. >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". Please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> will log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC9149 (draft-ietf-tls-ticketrequests) >>>> -------------------------------------- >>>> Title : TLS Ticket Requests >>>> Publication Date : April 2022 >>>> Author(s) : T. Pauly, D. Schinazi, C.A. Wood >>>> Category : Proposed Standard >>>> Source : tls (sec) >>>> Stream : IETF >>>> Verifying Party : IESG >>>> >>>> _______________________________________________ >>>> TLS mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>>
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
