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 <phoffman@xxxxxxxxxx> 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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
