[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

[David Benjamin <[e-mail]>]

On Fri, Apr 10, 2026, 09:07 Muhammad Usama Sardar <
[e-mail]> wrote:

> On 10.04.26 13:08, Bas Westerbaan wrote:
>
> # *Some editorial nits*
>>
>> Please move Sec. 3.3 to Appendix. Title has TLS 1.3. I was surprised to
>> see TLS 1.2 which has nothing to do with the title.
>>
> The section contains normative language and would be out of place in the
> appendix.
>
> Sorry but this may be a misunderstanding (either mine or yours). Does
> Informational vs. Standard Track make a difference here? Because for the
> latter, I see ca. 30 normative MUST in in Appendix of RFC-to-be 9846.
> Please correct me if I am misunderstanding something.
>
> We could remove "1.3" from the title.
>
> Sure, that would have worked for me, but doesn't that contradict
> draft-ietf-tls-tls12-frozen? Could we simply remove the whole TLS 1.2
> section? We agreed we will not provide PQC for TLS 1.2. So IMHO, it seems
> completely irrelevant to the milestones of the WG, and the draft should not
> make opinions on irrelevant issues.
>

This was discussed at the meeting, in meeting chat, and on list. We agreed
we will not provide PQC for TLS 1.2. We need to actually do that.

Whenever we work on TLS, we have to always remember that all versions of
TLS are joined at the hip. They share a ClientHello, implementations
typically support a range of versions, and a client sends a single
ClientHello that is good for all versions it supports. TLS versions also
share ClientHello fields, including signature algorithms here.

To define a codepoint in a shared space, how that codepoint interacts with
all TLS versions must be well-defined. Saying nothing leaves it ambiguous
whether the new codepoint applies to TLS 1.2. Remember, a TLS 1.2+1.3
client *will* send this codepoint to TLS 1.2 servers simply due to how the
protocol works. This is something the WG deals with whenever it adds stuff
like this.

That means this section is worthwhile and has a place in this document.

(As a minor technicality, because TLS 1.2 actually constrains the key type
in two places and there are no ML-DSA cipher suites or client certificate
types for TLS 1.2, one could argue those implicitly take it away. However,
this is a subtle point and, in the client certificate type direction,
inconsistently enforced by real world implementations. Thus it is better to
be clear and explicit.)

David