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

[Eric Rescorla <[e-mail]>]

On Mon, Mar 17, 2025 at 9:41 PM Paul Hoffman <[e-mail]> wrote:

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

The Recommended column is saying something different (you will notice it
also does not capture MUST vs SHOULD for Y).

I do agree that the documents which *set* the column should provide some
normative language.

-Ekr