There is actually a reason to not support these codepoints in TLS 1.2. Or rather it is not mechanically possible to use these codepoints in TLS 1.2, due to how TLS 1.2 works, but this fact is probably not obvious to most readers. (There is no mapping from ML-DSA to TLS 1.2 cipher suites or ClientCertificateType, which are necessary to use it for the server and client key, respectively.) Conversely, even though they aren't defined for use with TLS 1.2, what that means can be non-obvious because a TLS 1.2+1.3 client would still send these, which means a TLS 1.2 server would still see them (and ignore them) in the ClientHello.
On Tue, Jun 9, 2026 at 7:31 AM Bas Westerbaan <bas= [email protected]> wrote: > Hi Charlie, > > Thanks for the review. > > >> (3) Section 3.3 explicitly says that these algorithms MUST NOT be used in >> TLS 1.2 or earlier versions. While it's hard to imagine anyone rushing out >> to support new algorithms in old protocols, I don't see why it is important >> to disallow them, and if they were to support them it would seem >> appropriate to use these same code points. > > > The normative language is indeed superfluous, certainly > after draft-ietf-tls-tls12-frozen lands; the comments was put in place to > be explicit. Martin Thomson and Usama Sardar also would like to see it go, > but otherwise the WG remained silent on the topic. This PR would remove the > normative language: > > https://github.com/tlswg/tls-mldsa/pull/37 > > Nit: >> First paragraph of section 3: "as follows as follows" should be "as >> follows" > > > https://github.com/tlswg/tls-mldsa/pull/38 > > Thank you, > > Bas > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
