HFDU, it is.

Deb

On Thu, Jun 11, 2026 at 1:30 PM Eric Rescorla <[email protected]> wrote:

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

Reply via email to