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]

Reply via email to