To add to this, I’m curious what motivated the decision to choose the ephemeral variants of FrodoKEM when reducing the parameter sets. Though the ephemeral variants would be appropriate for IKE since keys aren’t supposed to be reused, my takeaway from the comments in the last meeting was that the folks that have a preference between the two prefer the regular version since it grants an increased security margin for only ~0.3% increase in cipher text size.
Thanks, Kev Kitchens He/him/his > On Jul 8, 2025, at 11:49 AM, Scott Fluhrer (sfluhrer) > <[email protected]> wrote: > > Comments: > > This draft nowhere states what is actually in the Frodo KEi, KEr payloads. > Now, you might say that this is profoundly obvious (and yeah, I would tend to > agree with you) - I believe that you should state that explicitly. > > > You have 3 parameter sets with the AES version of Frodo, and 3 with the SHAKE > version of Frodo. Why? > > Can you cite use cases where: > The AES version is clearly better suited > The SHAKE version is clearly better suited > > If you can't (in both directions), then there is no reason to have both sets > of parameter sets - it gives more possibilities of incompatibly (because one > side selected the AES version and the other the SHAKE version). > > > In addition, it appears that Frodo key generation is considerably faster than > Frodo decapsulation - hence, doing truly ephemeral Frodo is fairly cheap. > With this in mind, would it make sense to prohibit reuse of the Frodo private > key? There is text in 3.2 which states that this is "expected"; however, > that comes short of a MUST NOT reuse statement. > > > In the security section, you write: > > In additon, due to the fragmentation of public key and cipthertext of > the IKE message when FrodoKEM is hybrided, the performance of the > IKEv2 may be affected and the chance of re-transmision of IKE packet > could become higher in some networking secnarios. > > Apart from the typos additon, cipthertext, re-transmision, secnarios (and > hybrided, but that clause could just be removed), this really is about > performance, not security (and hence belongs somewhere else). > > From: Wang Guilin <[email protected]> > Sent: Tuesday, July 8, 2025 4:48 AM > To: [email protected] <[email protected]>; [email protected] > <[email protected]> > Cc: [email protected] <[email protected]>; > [email protected] <[email protected]>; Wang Guilin > <[email protected]> > Subject: [IPsec] FW: New Version Notification for > draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt > > Dear all, > > Our draft "Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM" has > been updated to v01. Here are the two main changes made, as a response to > comments received at 122 meeting: > > * Restructured the draft. > * Reduced the point codes from 12 to 6 (eFrodoKEM). > > Also, we would like to ask group adoption, based on the mostly positive > discussions in mailing list, which were summarized on my presentation slides > at IETF 122 > https://datatracker.ietf.org/meeting/122/materials/slides-122-ipsecme-post-quantum-hybrid-key-exchange-in-the-ikev2-with-frodokem-00 > > The original discussion are also available at > https://mailarchive.ietf.org/arch/search/?q=Frodo&f_list=ipsec > > Dear chairs, > > We will appreciate if a time slot could be assigned for us to present this > draft at Mardid. > > Thanks, > > Guilin (On behalf of Leonie and Valery as well) > > -----Original Message----- > From: [email protected] <[email protected]> > Sent: Monday, 7 July 2025 7:13 pm > To: Wang Guilin <[email protected]>; Wang Guilin > <[email protected]>; Leonie Bruckert <[email protected]>; > Leonie Bruckert <[email protected]>; Valery Smyslov > <[email protected]> > Subject: New Version Notification for > draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt > > A new version of Internet-Draft > draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt has been successfully > submitted by Guilin Wang and posted to the IETF repository. > > Name: draft-wang-ipsecme-hybrid-kem-ikev2-frodo > Revision: 01 > Title: Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM > Date: 2025-07-07 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt > Status: > https://datatracker.ietf.org/doc/draft-wang-ipsecme-hybrid-kem-ikev2-frodo/ > HTML: > https://www.ietf.org/archive/id/draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.html > HTMLized: > https://datatracker.ietf.org/doc/html/draft-wang-ipsecme-hybrid-kem-ikev2-frodo > Diff: > https://author-tools.ietf.org/iddiff?url2=draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01 > > Abstract: > > Multiple key exchanges in the Internet Key Exchange Protocol Version > 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key > encapsulation mechanisms (KEMs) in the Internet Key Exchange Protocol > Version 2 (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 cryptanalytically relevant quantum computers (CRQC). For this > purpose, usually one or more post-quantum KEMs are performed in > addition to the traditional (EC)DH key exchange. This draft > specifies how the post-quantum KEM FrodoKEM is instantiated in the > 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 [I-D.KR24]. ] > > > > The IETF Secretariat > > > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [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]
