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

[Joseph Salowey <[e-mail]>]

Hi Paul,

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.

Cheers,

Joe



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.
>
> --Paul Hoffman
>