Hi Guilin, Thanks for that info; I agree that using the ephemeral variant makes sense given the requirement in draft-longa-cfrg-frodokem-00. I’m somewhat surprised that they're making this a MUST requirement since it seems to be a much stronger statement than the other specs for FrodoKEM make about the ephemeral variant.
Thanks, Kev Kitchens He/him/his > On Jul 9, 2025, at 9:16 AM, Wang Guilin > <Wang.Guilin=40huawei....@dmarc.ietf.org> wrote: > > Dear Kev and Valery, > > Thanks. > > Actually, the main reason for selecting ephemeral variant of FrodoKEM for > IKEv2 is according to the following recommendation given in Section 8 of [1]. > > "In addition, FrodoKEM consists of two main variants: a "standard" variant > that does not impose any restriction on the reuse of key pairs, and an > "ephemeral" variant that is intended for applications in which the number of > ciphertexts produced relative to any single public key is small. Concretely, > the use of standard FrodoKEM is recommended for applications in which the > number of ciphertexts produced for a single public key is expected to be > equal or greater than 2^8. Ephemeral FrodoKEM MUST be used for applications > in which that same figure is expected to be smaller than 2^8. " > > We also explained this in Section 3.2 of our draft. > > Of course, however, we are happy to see more comments on how it is better to > select the variants here. > > Guess some of the authors of [1] are in this mailing list as well. > > Cheers, > > Guilin > > [1] FrodoKEM: key encapsulation from learning with errors > draft-longa-cfrg-frodokem-00 > https://datatracker.ietf.org/doc/draft-longa-cfrg-frodokem/ > > 发件人：Valery Smyslov <smyslov.i...@gmail.com <mailto:smyslov.i...@gmail.com>> > 收件人：'Kev Kitchens' <kkitch...@apple.com <mailto:kkitch...@apple.com>>;'Scott > Fluhrer (sfluhrer)' <sfluh...@cisco.com <mailto:sfluh...@cisco.com>>;Wang > Guilin <wang.gui...@huawei.com <mailto:wang.gui...@huawei.com>>;ipsec > <ipsec@ietf.org <mailto:ipsec@ietf.org>>;ipsecme-chairs > <ipsecme-cha...@ietf.org <mailto:ipsecme-cha...@ietf.org>>;Leonie.Bruckert > <leonie.bruck...@secunet.com <mailto:leonie.bruck...@secunet.com>> > 时 间：2025-07-09 16:19:47 > 主 题：RE: [IPsec] New Version Notification for > draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt > > Hi Kev, > > good observation, thank you. Perhaps it makes sense, we will think about this. > > Regards, > Valery. > > From: Kev Kitchens <kkitch...@apple.com> > Sent: Tuesday, July 8, 2025 10:20 PM > To: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org>; Wang > Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org>; ipsec@ietf.org; > ipsecme-cha...@ietf.org; leonie.bruck...@secunet.com; smyslov.i...@gmail.com > Subject: Re: [IPsec] New Version Notification for > draft-wang-ipsecme-hybrid-kem-ikev2-frodo-01.txt > > 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) > <sfluhrer=40cisco....@dmarc.ietf.org> 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 <Wang.Guilin=40huawei....@dmarc.ietf.org> > Sent: Tuesday, July 8, 2025 4:48 AM > To: ipsec@ietf.org <ipsec@ietf.org>; ipsecme-cha...@ietf.org > <ipsecme-cha...@ietf.org> > Cc: leonie.bruck...@secunet.com <leonie.bruck...@secunet.com>; > smyslov.i...@gmail.com <smyslov.i...@gmail.com>; Wang Guilin > <wang.gui...@huawei.com> > 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: internet-dra...@ietf.org <internet-dra...@ietf.org> > Sent: Monday, 7 July 2025 7:13 pm > To: Wang Guilin <wang.gui...@huawei.com>; Wang Guilin > <wang.gui...@huawei.com>; Leonie Bruckert <leonie.bruck...@secunet.com>; > Leonie Bruckert <leonie.bruck...@secunet.com>; Valery Smyslov > <smyslov.i...@gmail.com> > 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 -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org <mailto:ipsec@ietf.org> > To unsubscribe send an email to ipsec-le...@ietf.org > <mailto:ipsec-le...@ietf.org> > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org <mailto:ipsec@ietf.org> > To unsubscribe send an email to ipsec-le...@ietf.org > <mailto:ipsec-le...@ietf.org>
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
