[TLS] Re: Last Call: <draft-ietf-tls-rfc8447bis-11.txt> (IANA Registry Updates for TLS and DTLS) to Proposed Standard

[Paul Hoffman <[e-mail]>]

On 17 Mar 2025, at 17:40, Joseph Salowey wrote:

> The draft already contains the following guidance to address this point on
> how to treat items marked as "D":
>
> "D: Indicates that the item is discouraged. This marking could be used to
> identify mechanisms that might result in problems if they are used, such as
> a weak cryptographic algorithm or a mechanism that might cause
> interoperability problems in deployment. Implementers SHOULD consult the
> linked references associated with the item to determine the conditions
> under which it SHOULD NOT or MUST NOT be used."
>
> The behavior of TLS when it cannot arrive on an acceptable set of
> parameters is defined in the TLS protocol specification.

This does not address my comments:

> On Fri, Mar 14, 2025 at 1:59 AM Paul Hoffman <[e-mail]> wrote:
>
>> Greetings again. The contents of this draft are fine but definitely
>> incomplete. The draft gives clear language about whether particular
>> cryptographic components are recommended for use in TLS, but no guidance
>> for implementations of what those implementations should do if given a
>> discouraged code point.
>>
>> If a TLS server negotiates to a cryptographic component labelled "D". what
>> SHOULD / MUST the client do?
>>
>> If a TLS client only offers D-level components, what SHOULD / MUST the
>> server do?
>>
>> A program's configuration mechanism SHOULD NOT / MUST NOT allow specifying
>> D-level components?
>>
>> This draft should either be expanded to say what TLS clients and servers
>> and configuration SHOULD / MUST do with D-level components. If it is too
>> difficult for the TLS WG to agree on specific actions, the draft should at
>> least say that so that the reader knows what to do with these new ratings.
>> Without such wording, the new "D" label becomes useless in practice, which
>> is clearly bad for security and interoperability.

The wording:
> Implementers SHOULD consult the
> linked references associated with the item to determine the conditions
> under which it SHOULD NOT or MUST NOT be used.
...doesn't help software developers in many cases. Let's look at the first value in Section 4, truncated_hmac. The "linked reference" is Section 7 of RFC 6066. From the wording there, using truncated_hmac is just fine, even though draft-ietf-tls-rfc8447bis gives it a "D".

So, again: This draft should either be expanded to say what TLS clients and servers and configuration SHOULD / MUST do with D-level components, or tell readers why it is not. Telling developers "go look at every doc that is liked from a D-level spec" is likely to cause them to not do so, and the result will be insecure implementations and lack of interoperability.

--Paul Hoffman