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 To unsubscribe send an email to ipsec-le...@ietf.org
