Hi all, I reviewed the draft and I think that overall it looks good (though it could use a good spellchecking pass, see also below).
Adoption: On the question of support for adoption: if the IPsec WG is happy to have drafts/RFCs for all key exchange algorithms instead of just registering code points, then this draft should be adopted. I don’t think this draft specifies much that the ML-KEM draft did not already cover. At the same time, I guess this draft is helpful to document WG consensus on which variants of FrodoKEM (namely, not eFrodoKEM) are appropriate. Title: I do strongly feel that “hybrid” should be removed from the title of the draft, because I think it will lead to confusion on what this draft achieves in terms of security. Namely, “hybrid” commonly means PQ/T hybrids, but this draft can be used perfectly fine with ML-KEM-512 in the IKE_SA_INIT key exchange. While I do agree that this would still give us a (PQ/PQ) “hybrid”, I don’t think that this matches expectations surrounding the word “hybrid”. I don’t think “hybrid” adds much either, other than (to experts) hinting that this needs to be done in IKE_INTERMEDIATE exchanges. So if that is the intended message, I suggest renaming the draft to something like “FrodoKEM for IKE_INTERMEDIATE IKEv2 Key Exchanges”. ephemeral FrodoKEM: I think that ISO specifying ephemeral FrodoKEM is a mistake, because it is only extremely marginally smaller than regular FrodoKEM. I vaguely remember someone involved in that process stating that it was necessary due to some legacy stuff using it. Let’s not add to that legacy by considering eFrodoKEM (which this draft indeed does not). I think there is enough text already discussing eFrodoKEM, possibly even too much. Editorial comments: This is based on a quick read, not an in-depth review, so I probably missed stuff. 1.2: “… based on structured lattice.” -> structured lattices (plural) " Therefore, this specification is motivated to describe concretely how the framework of hybrid KEMs for IKEv2 specified in RFC 9370 can be instantiated with FrodoKEM.” -> this sentence can be greatly simplified and made active voice: “This specification describes concretely how …" 3.2: “To cover both scenarios, this specification SHALL include both variants.” I don’t think SHALL is appropriate to describe something that the text of this draft itself is doing. The keywords are for interoperability hazards only, AIUI. Section 4 describes in great detail wha the behaviour of IKE Multiple Key exchanges is when instantiated with FrodoKEM. There is so much detail in fact, that I worry that there may be subtle differences and using normative language (MUST/MAY/SHALL, etc) could lead to different meanings. It could be smart to write that RFC 9370 is the normative text. Section 4.1: “(refere to section 2.2.2…)” -> refers "Following general exmaples given in Appendix A…” -> examples Section 5: "Downgrade attacks on the authentication part of IKEv2 has been identied and repaired “ -> have (singular plural disagreement); identified. The title of the draft referenced is also inaccurate. Cheers, Thom > Op 12 jan 2026, om 19:09 heeft Tero Kivinen via Datatracker > <[email protected]> het volgende geschreven: > > This message starts a ipsecme WG Call for Adoption of: > draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 > > This Working Group Call for Adoption ends on 2026-02-09 > > Abstract: > Multiple key exchanges in the Internet Key Exchange Protocol Version > 2 (IKEv2) [RFC9370] specifies a framework, which supports multiple > key encapsulation mechanisms (KEMs) in IKEv2 by allowing up to 7 > layers of additional KEMs to derive the final shared secret keys for > IPsec protocols. The primary goal is to mitigate the “harvest now > and decrypt later” threat posed by Cryptographically Relevant Quantum > Computers(CRQCs). For this purpose, one or more post-quantum KEMs > are usually performed in addition to the traditional (EC)DH key > exchange. This draft specifies how the post-quantum KEM algorithm > FrodoKEM is instantiated for IKEv2 as an additional key exchange > mechanism. > > [EDNOTE: IANA KE code points for FrodoKEM may need to be assigned, as > the code points for ML-KEM has been considered in [W-D.K25]. ] > > Please reply to this message and indicate whether or not you support adoption > of this Internet-Draft by the ipsecme WG. Comments to explain your preference > are greatly appreciated. Please reply to all recipients of this message and > include this message in your response. > > Authors, and WG participants in general, are reminded of the Intellectual > Property Rights (IPR) disclosure obligations described in BCP 79 [2]. > Appropriate IPR disclosures required for full conformance with the provisions > of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. > Sanctions available for application to violators of IETF IPR Policy can be > found at [3]. > > Thank you. > [1] https://datatracker.ietf.org/doc/bcp78/ > [2] https://datatracker.ietf.org/doc/bcp79/ > [3] https://datatracker.ietf.org/doc/rfc6701/ > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
