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 <phoff...@proper.com> 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
