On Mon, Mar 17, 2025 at 9:41 PM Paul Hoffman <phoffman@xxxxxxxxxx> 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 <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.
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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
