To address potential fragmentation issues when using IKEv2 with standalone FrodoKEM key exchange, the mechanism defined in https://datatracker.ietf.org/doc/draft-reddy-ipsecme-ikev2-hybrid-reliable/ can be utilized. This is particularly relevant for deployments that want to bypass the initial traditional key exchange.
Cheers, -Tiru On Fri, 23 Jan 2026 at 18:36, Scott Fluhrer (sfluhrer) <sfluhrer= [email protected]> wrote: > 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 <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 > <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] > <[email protected]>*> > *Date: *Friday, 23 January 2026 at 10:12 > *To: *Ben S3 <*[email protected] > <[email protected]>*>, Michael Richardson > <*[email protected] > <[email protected]>*>, Thom Wiggers <*[email protected] > <[email protected]>*>, *[email protected] <[email protected]>* <*[email protected] > <[email protected]>*> > *Cc: *Wang Guilin <*[email protected] <[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] > <[email protected]>*> > Sent: Friday, 23 January 2026 4:12 pm > To: Michael Richardson <*[email protected] <[email protected]>*>; > Thom Wiggers <*[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) > > 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] <[email protected]>*> > Sent: 22 January 2026 21:07 > To: Thom Wiggers <*[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) > > > Thom Wiggers <*[email protected] <[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] <[email protected]>*> . > o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > IPsec mailing list -- *[email protected] <[email protected]>* > To unsubscribe send an email to *[email protected] > <[email protected]>* > _______________________________________________ > IPsec mailing list -- *[email protected] <[email protected]>* > To unsubscribe send an email to *[email protected] > <[email protected]>* > _______________________________________________ > 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]
