Scott Fluhrer (sfluhrer) >Now, it may be quite common to do this, but it is not necessary. For example, >if you're doing IKE over TLS, there may be no need. Alternatively, you might >do a PQ KEM that fits within the first exchange. I would recommend that this >draft should back off from assuming that Frodo can be used only in the >"Classical+Frodo" combination.
I strongly agree with this. This and other PQC algorithm documents should focus on registering key exchange algorithm. How do combine algorithms is profiling, and something that should definitely be left to another document. >mainly for the case to run FrodoKEM via ADDKE together with traditional ECDHE I disagree, I think the document should give this as an example but otherwise not care if you are running ECDHE+FrodoKEM, DHE+FrodoKEM, standalone FrodoKEM, ML-KEM+FrodoKEM, or HQC-KEM+FrodoKEM, etc. John From: Wang Guilin <[email protected]> Date: Thursday, 22 January 2026 at 18:58 To: Scott Fluhrer (sfluhrer) <[email protected]>, Wang Guilin <[email protected]>, Thom Wiggers <[email protected]>, Tero Kivinen <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) Thanks for your detailed comments, Scott. Yes, you are right. Even the draft is mainly for the case to run FrodoKEM via ADDKE together with traditional ECDHE, but it should not exclude the case when FrodoKEM is run in IKE_SA_INIT over TLS. Also, it is helpful for receiving the comments on subtle differences among "will", "shall", "SHALL", "MUST" etc.. Guilin 发件人：Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> 收件人：Wang Guilin <[email protected]<mailto:[email protected]>>;Thom Wiggers <[email protected]<mailto:[email protected]>>;Tero Kivinen <[email protected]<mailto:[email protected]>> 抄 送：[email protected] <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>;Wang Guilin <[email protected]<mailto:[email protected]>> 时 间：2026-01-22 00:00:03 主 题：Re: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) Minor nits (which really don't have anything to do with the call for adoption): Working with classical: the draft states "As specified in [RFC9370], to run PQ KEMs in IEKv2, the initiator and the responder SHALL run traditional key exchange first and then PQ KEMs." Actually, RFC 9370 does not mandate this; instead, RFC 9370 specifically permits all supported key exchanges be done initially. Now, it may be quite common to do this, but it is not necessary. For example, if you're doing IKE over TLS, there may be no need. Alternatively, you might do a PQ KEM that fits within the first exchange. I would recommend that this draft should back off from assuming that Frodo can be used only in the "Classical+Frodo" combination. Usage of SHALL: I believe that all-caps SHALL should be used when instructing the implementor about requirements on the implementation. Sometimes, SHALL is used correctly; other times, not so much. For example: "To cover both scenarios, this specification SHALL include both [SHAKE and AES] variants". This is not an instruction to the implementor - instead, it is an instruction to the draft authors (unless the intention was to require that implementations support both transforms, and if so, the text should be considerably more explicit. Another example: "Once these procedures are done successully [sic], the two entities SHALL share the same raw key SK(0)" - again, you mean 'will', not 'SHALL' (because, other than fixing bugs, there's nothing the implementation can do to make this happen). The FrodoKEM specification [I-D.LBES25] - that sounds normative to me. Yes, I do realize that making normative reference to an internet draft is a blocker when this is about to become an RFC - that's quite a while away. ________________________________ From: Wang Guilin <[email protected]> Sent: Wednesday, January 21, 2026 9:42 AM To: Thom Wiggers <[email protected]>; Tero Kivinen <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; Wang Guilin <[email protected]> Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) Thank you all for the comments and support. In particular for the detailed suggestions from Thom on compressing /improving the text. About the title, we will consider it a little later to see if there are other comments. Guilin 发件人：Thom Wiggers <[email protected]<mailto:[email protected]>> 收件人：Tero Kivinen <[email protected]<mailto:[email protected]>> 抄 送：[email protected] <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>>;[email protected] <[email protected]<mailto:[email protected]>> 时 间：2026-01-21 17:27:08 主 题：Re: [IPsec] Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) 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]
