Hi, I support registering code points, and I support adoption as long as the specification will not link normatively to paywalled crypto specifications in the future. Paywalled crypto is a cybersecurity risk and I think access to crypto specifications is a human right.
Reason to adopt is that several governments are recommending FrodoKEM. But I note that ASNSSI is now placing FrodoKEM and ML-KEM in the same confidence class. For industry, ML-KEM + HQC-KEM is a more performant solution for people wanting a more conservative solution than standalone ML-KEM. https://na.eventscloud.com/file_uploads/b635298de1c10be6d3732863e8b1beca_Day2-1600-ANSSI.pdf https://csrc.nist.gov/csrc/media/Events/2025/workshop-on-guidance-for-kems/documents/papers/ml-kem-is-great-paper.pdf Comments: I think this and a lot of other PQC drafts are way too long. We don't need yet another draft explaining PQC background. Just focus on the code point registrations and slim it down. --- OLD Computers(CRQCs) NEW Computers (CRQCs) --- >To cover both scenarios, this specification SHALL include both variants. weird to have a SHALL on your own specification --- I think this should be removed: "Generally speaking, post-quantum algorithms are still not mature yet. Some algorithms may turn out to be insecure after a number of years’ study and/or standardization. An example is SIKE, which had been in the NIST standardization progress for several years until it was totally broken in July of 2022 [CD22]." ---- I think the abstract talks to much about PQ/T hybrids and “harvest now and decrypt later”. It will be several years until this is published and we are just 9 years away from when NIST and others will consider ECDHE and FFDHE to not provide any security. “harvest now and decrypt later” will not an outdated term as soon as someone builds a CRQC. Cheers, John
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
