Thanks Bas for starting this discussion Thomas Bellebaum wrote: >a big yes to recommending X25519MLKEM768 as soon as possible. >I would even go further and update the mandatory-to-implement >section of RFC 8446 (which looks interesting right now with >some potential "D" algorithms).
Fully agree. I think making X25519MLKEM768 should be MTI as soon as possible, it is already the de facto standard, and will very likely remain so for at least a decade. The quicker we make X25519MLKEM768 MTI we can make quantum-vulnerable algorithms non-MTI, which is important. Note that there is no contradiction in having MTI "D" algorithms. Unless we ramp up the version to 1.4, I think we need to have both X25519MLKEM768 and secp256r1 as MTI for a while. Sophie Schmieg wrote: >I think independently of that, we should start an effort of moving >classical only algorithms to N or D. D might sound aggressive now, but note >that e.g. NIST has already marked them as deprecated by 2030. Unless I missed something. It is only ffdhe2048 and the RSA-2048 signatures in TLS 1.3 that NIST will deprecate by 2030. secp256r1 is approved until 2035 when it will be disallowed. And the de facto standard x25519 has never been approved by NIST and due to the PQC transition, never will. https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf<https://nvlpubs.nist.gov/nistpubs/ir/2024/NIST.IR.8547.ipd.pdf?utm_source=chatgpt.com> That said, I agree we should start moving classical only algorithms to N or D. In my view, quantum-vulnerable key exchange should not be more recommended than standalone ML-KEM and HQC-KEM (which I hope will be registered in the future together with hybrids). Cheers, John Preuß Mattsson
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
