I don’t think the proposed PR is technically correct. The quantum-vulnerable algorithms secp256r1, secp384r1, X25519, and X448 are also marked RECOMMENDED=Y. Moreover, the fact that TLS currently recommends standalone quantum-vulnerable key exchange more strongly than standalone quantum-resistant key exchange is probably not something we want to codify in an RFC. The purpose of the IANA RECOMMENDED column is precisely to avoid embedding such these kind of policy decisions in RFC text.
I find the existing text in the draft quite good, except that "PQ/T" will not age well. X25519MLKEM768 is already the de facto standard, so I do not think it needs much additional promotion. My takeaway from the recent discussions is that there is a significant risk that people will assume PQ/T provides more security and robustness than it actually does. While PQ/T can continue to be used for many years, we are quickly approaching the point (2029?) where the IETF should stop implying that the traditional component contributes meaningful security. Cheers, John Preuß Mattsson From: Filippo Valsorda <[email protected]> Date: Monday, 8 June 2026 at 01:27 To: [email protected] <[email protected]> Subject: [TLS] Re: FATT Chance: On the Robustness of Standalone and Hybrid ML-KEM Key Exchange in TLS 1.3 2026-06-08 01:05 GMT+02:00 Muhammad Usama Sardar <[email protected]<mailto:[email protected]>>: [0] https://github.com/tlswg/draft-ietf-tls-mlkem/pull/21 I agree with the point made by others before that a spec for X doesn’t have to compare it with Y, or reproduce the rest of the IANA registry Recommended column, so I disagree with this PR.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
