First off: Yay, post quantum certificates! As much as I think ML-DSA is not a good fit for TLS (mostly because of how big each signature/pk pair is), I fully support publication on the basis that we need to start
getting these things deployed whether we like 'em or not. So yes, let's get this published! HOWEVER I have concerns about the cadence (or, the lack of cadence) in regards to *how* these new PQ suites will be adopted. I think it makes sense to keep confidentiality in the wild west of who-supports-what, but I do seriously recommend the TLS WG look at formalizing how PQ certs are to be adopted by the world at large. There is already confusion in regards to what "post-quantum" actually means, and I don't think passing the responsibility to choose policies is going to make this transition any easier. I see this as a deployability issue, despite it not being technical in nature. (I'd like to take a moment to remind everyone of the phrase "military-grade encryption"; which "post-quantum" is rapidly devolving into) Eg, the following configurations could be argued to be "post-quantum secure" (or even advertised as such!): - Clients that support ML-KEM but do not support ML-DSA; (or clients that require ML-KEM but do not require ML-DSA) - Clients that require ML-KEM and ML-DSA for TLS 1.3, but not for earlier editions of TLS (eg, for compatibility reasons) - Clients that support ML-DSA but do not support the server's post- quantum ciphersuite portfolio, and thus negotiate a pre-quantum alternative Chiefly, post-quantum security can truly only ever happen *on the client*. While servers supporting post-quantum cryptography is an ESSENTIAL step, it will all be for moot if the client accepts the use of pre-quantum suites. There have been several proposals that aim to address this; declaring a "Quantum-Day" where everyone just agrees to stop using vulnerable algorithms, using "quantum cookies" to remember which servers support PQ in a similar manner to HSTS, etc. I have my own proposal for how to declare this cadence: by splitting clients into "Quantum-Passive" and "Quantum-Active" configurations. In "Quantum-Passive", we only guarantee post-quantum security for passive classical attackers when both parties support it (the optional use of ML-KEM, and the use of a classical signature algorithm), while in "Quantum-Active" we guarantee the post-quantum security against active quantum attackers by outright rejecting classical suites. For example, an RFC describing this deployment protocol could read a little something like this: > X.1 Quantum-Passive Clients > > Quantum-Passive Clients MUST advertise support for at least one > post-quantum key agreement suite, and are STRONGLY RECOMMENDED > to additionally advertise support of at least one post-quantum > signature suite. > > Quantum-Passive Clients MUST NOT accept the combination of a > post-quantum signature suite and a pre-quantum key agreement > suite; should the server attempt to negotiate such a combination, > the client MUST abort the connection attempt. However, a Quantum- > -Passive client MUST accept the combination of a post-quantum key > agreement suite and a pre-quantum signature suite. > > X.2 Quantum-Active Clients > > Quantum-Active Clients MUST advertise support for at least one > post-quantum key agreement suite, and MUST additionally advertise > support of at least one post-quantum signature suite. > > Quantum-Active Clients MUST NOT advertise support for any pre- > quantum suites, and MUST reject any attempts to negotiate such > suites by the server. > > Quantum-Active Clients MUST only support TLS Version 1.3 or above, > and MUST NOT support connections over lower versions of TLS. ...Alongside the following change in the ML-DSA draft, or something similar: > 3.4 Quantum Readiness > > ML-DSA is secure against all known classical and quantum attacks, > and is supported as a post-quantum signature suite for both > Quantum-Passive and Quantum-Active clients. > > To comply with the Quantum-Passive requirements, a server MUST NOT > select ML-DSA to be used in combination with a non-post-quantum > key agreement suite. In other words, when the server negotiates > a pre-quantum confidentiality suite, the server MUST NOT utilize > ML-DSA for handshaking. I'd fully respect a decision that these sorts of changes are well outside the scope of this specific I-D. However, I do believe it is critical for post-quantum adoption to ensure that the post-quantum readiness of any client can be easily articulated, and that such definitions of readiness are agreed upon by vendors of client software. I don't want adoption of these certificates to get bogged down in confusion about how exactly the process of becoming quantum-ready works. For example, just the other day, I picked up a brochure about a firewall product that performed posture management for PQ adoption. This software marked all clients merely supporting ML-KEM as "Quantum Secure", despite the fact that such clients did not support the use of PQ certificates, and that such clients only optionally supported ML-KEM (and there is no way for the software to know that the client would have DEMANDED the use of PQ certs/key agreement). It's a Fortune 500 company, which I won't be naming because the point here isn't to shame them, it's just to show that the confusion over vocabulary is real, it is happening now, and we need to get ahead of it if this draft is going to be properly adopted and utilized by the world at large. Best, Joshua Nabors On Thursday, April 9th, 2026 at 12:31 PM, Sean Turner <[email protected]> wrote: > This is the working group last call for Use of ML-DSA in TLS 1.3. Please > review draft-ietf-tls-mldsa [1] and reply to this thread indicating if you > think it is ready for publication or not. If you do not think it is ready > please indicate why. This call will end on April 23, 2026. > > REMINDER: If you have not done so recently, review the TLS WG's Mail List > Procedures; see [2]. > > The Chairs, > Deirdre, Joe, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-mldsa/ > [2] https://mailarchive.ietf.org/arch/msg/tls/ucdImHExlbOf4Q3BCG81gjzi2xE/ > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
