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]
