On Mon, Mar 17, 2025 at 9:41 PM Paul Hoffman <[email protected]> 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 <[email protected]> > 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
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
