The option you suggest below of negotiating "NONE" as the first key exchange is (IMHO) Evil, and I would call for it to be rejected. If you want to do FrodoKEM only (and you don't have MTU concerns, either because you're going over TLS, or your L2 protocol has a large MTU size), then make FrodoKEM as your first (and only) key exchange - problem solved.
________________________________ From: Wang Guilin <[email protected]> Sent: Friday, January 23, 2026 5:25 AM To: John Mattsson <[email protected]>; Wang Guilin <[email protected]>; Ben S3 <[email protected]>; Michael Richardson <[email protected]>; Thom Wiggers <[email protected]>; [email protected] <[email protected]> Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) I see. But the draft is not restricting how implementations are using FrodoKEM. Instead, we are considering to expend the draft for running pure FrodoKEM over TLS, as suggested by Scott. This case is not covered in the current version 03. Also, I am think if we can run pure FrodoKEM (or any PQ KEM) in IKEv2 under the framework of RFC 9370 as follows. * In IKE_SA_INIT, KE payload includes NONE as the traditional KE. Note that NONE, no KE at all, has 0 as its KE Method Transform ID, according to the IANA IKEv2 parameters, https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml. * Later, run Intermediate exchange to exchange the public key and ciphertext of FrodoKEM via ADDKE, as specified by FRC 9370. * Namely, the means NONE+FrodoKEM=FrodoKEM. * Not sure if this works and is good in IKEv2 practice? Guilin From: John Mattsson <[email protected]> Sent: Friday, 23 January 2026 6:03 pm To: Wang Guilin <[email protected]>; Ben S3 <[email protected]>; Michael Richardson <[email protected]>; Thom Wiggers <[email protected]>; [email protected] Cc: Wang Guilin <[email protected]> Subject: Re: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) >- Still, the main part for our draft is about how to use FrodoKEM in hybrid >way (traditional KE+FrodoKEM), though more PQ KEMs can be added by following >RFC 9370. I disagree with this, I think the main part of IPSECME’s draft should be to register code points for FrodoKEM without restricting how implementations are using FrodoKEM. John From: Wang Guilin <[email protected]<mailto:[email protected]>> Date: Friday, 23 January 2026 at 10:12 To: Ben S3 <[email protected]<mailto:[email protected]>>, Michael Richardson <[email protected]<mailto:[email protected]>>, Thom Wiggers <[email protected]<mailto:[email protected]>>, [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: Wang Guilin <[email protected]<mailto:[email protected]>> Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) Yes, this true. Also considering what a better name for our draft draft-wang-ipsecme-hybrid-kem-ikev2-frodo. And this may also indicate similar issue for draft-ietf-ipsecme-ikev2-mlkem. For draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03: - Current title: "Post-quantum Hybrid Key Exchange in IKEv2 with FrodoKEM" - Michael Richardson: "Using FrodoKEM in Multiple IKEv2 Key Exchanges" - Thom Wiggers: “FrodoKEM for IKE_INTERMEDIATE IKEv2 Key Exchanges - Scott Fluhrer: No exact name suggested, but commented: "I would recommend that this draft should back off from assuming that Frodo can be used only in the "Classical+Frodo" combination." For me, I like the current one or that from Michael. A few reasons: - Still, the main part for our draft is about how to use FrodoKEM in hybrid way (traditional KE+FrodoKEM), though more PQ KEMs can be added by following RFC 9370. - The draft can describe how to run pure FrodoKEM over TLS, as Scott suggested. But this is a smaller case in the draft. - For my understanding, hybrid is more general than just T/PQ. It refers two or more crypto component algorithms are combined to achieve a security purpose. (Also, how to combine the component algorithms and how strong the resulting solution are further issues.) - RFC 9794 seems not giving definition for "hybrid", but mentions that it can be used for T/PQ (like hybrid KE defined by ETSI) or a more general concept (like hybrid KE defined by NIST). Details can be found in Section 1 of RFC 9794. draft-ietf-ipsecme-ikev2-mlkem: - Current title: "Post-quantum Hybrid Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2)" This WG document does specify how to use pure ML-KEM in IKEv2. Abstract tells "This draft specifies how to use ML-KEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange." Guilin -----Original Message----- From: Ben S3 <[email protected]<mailto:[email protected]>> Sent: Friday, 23 January 2026 4:12 pm To: Michael Richardson <[email protected]<mailto:[email protected]>>; Thom Wiggers <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) OFFICIAL Without stating an opinion either way, I’ll note that the title of this draft is consistent with the title of draft-ietf-ipsecme-ikev2-mlkem, which also assumes hybrid. Of course, the solution here might be “change the name of the ML-KEM draft too”. Ben OFFICIAL -----Original Message----- From: Michael Richardson <[email protected]<mailto:[email protected]>> Sent: 22 January 2026 21:07 To: Thom Wiggers <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: [IPsec] Re: Call for adoption: draft-wang-ipsecme-hybrid-kem-ikev2-frodo-03 (Ends 2026-02-09) Thom Wiggers <[email protected]<mailto:[email protected]>> wrote: > 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 agree strongly. RFC9370 defines multiple key exchanges, so linking it in that way makes more sense. > 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”. Or, maybe "Using FrodoKEM in Multiple IKEv2 Key Exchanges" -- Michael Richardson <[email protected]<mailto:[email protected]>> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ IPsec mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> _______________________________________________ IPsec mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
