ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their list of recommended algorithms, which I very much welcome, but I have not seen any indication that they would stop recommending FrodoKEM. My current understanding is that many European governments are planning to use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral key exchange for their national security systems. Like the US more algorithms might be allowed for government systems that are not national security systems.
https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_stephan-ehlen_bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_jerome-plut_anssi_anssi-plan-for-post-quantum-transition.pdf https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf https://cyber.gouv.fr/sites/default/files/document/pqc-transition-in-france.pdf http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf John From: Michael Osborne <o...@zurich.ibm.com> Date: Wednesday, 22 January 2025 at 20:39 To: Loganaden Velvindron <logana...@gmail.com>, John Mattsson <john.matts...@ericsson.com> Cc: Wang Guilin <wang.gui...@huawei.com>, ipsec <ipsec@ietf.org>, cfrg <c...@irtf.org>, Wang Guilin <wang.gui...@huawei.com> Subject: RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 [You don't often get email from o...@zurich.ibm.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi John You want to check this statement " Many European governments are planning to use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral key exchange" The Netherlands have already updated guidance such that ML-KEM is recommended and FrodoKEM is acceptable. https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublications.tno.nl%2Fpublication%2F34643386%2FfXcPVHsX%2FTNO-2024-pqc-en.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888408248%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=d0eSQESgqm9ntxphpjmg2KriyCA5TxBlBI19VkpYJaY%3D&reserved=0<https://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.pdf> I understand BSI Germany and others will do the same shortly Kind Regards Mike -----Original Message----- From: Loganaden Velvindron <logana...@gmail.com> Sent: Wednesday, January 22, 2025 7:11 PM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Cc: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org>; ipsec <ipsec@ietf.org>; cfrg <c...@irtf.org>; Wang Guilin <wang.gui...@huawei.com> Subject: [EXTERNAL] [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 On Wed, 22 Jan 2025 at 17:05, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > Hi, > > > > I think IKEv2 should register code points for FrodoKEM and BIKE/HQC > (depending on which one NIST standardizes). I think it is important with > backups to ML-KEM. The importance of cryptographic agility has been > emphasized by several US agencies. A necessity for cryptographic agility is > to have a cryptographic primitive to switch to. The practice of implementing > cryptographic backup algorithms has long been a guiding principle in the > telecom industry. > Indeed. Cryptographic agility is good. I've also seen this from wolfssl: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wolfssl.com%2Fcoming-soon-frodokem-in-wolfcrypt%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888424244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tZbHySbq7mntNnFNM7sEXxmBTvQ9G3LQgbJ9Zs0jp2Y%3D&reserved=0<https://www.wolfssl.com/coming-soon-frodokem-in-wolfcrypt/> > > > FrodoKEM is unstructuctured but still lattice, BIKE/HQC is code-based but > still structured. Many European governments are planning to use FrodoKEM as > the main quantum-resistant algorithm for ephemeral-ephemeral key exchange. > For an ESP association sending 100 GB of data, the overhead of FrodoKEM and > BIKE/HQC is small. > > > > Classic McEliece could also be considered but I think it is mostly > interesting for static encapsulation keys like in HPKE. > > > > I think CFRG should specify FrodoKEM, but I am also fine with continue using > frodokem.org as a normative reference. > > > > Cheers, > > John > > > > From: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org> > Date: Wednesday, 6 November 2024 at 15:22 > To: plonga <plo...@microsoft.com> > Cc: ipsec <ipsec@ietf.org>, cfrg <c...@irtf.org>, Wang Guilin > <wang.gui...@huawei.com> > Subject: [CFRG] [IPsec]: FrodoKEM and its usage in IKemEv2 > > Dear Patrick, > > > > As disccussed during your talk about FrodoKEM in the CFRG meeting, here is > the info about our draft. > > > > Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM > > draft-wang-hybrid-kem-ikev2-frodo-02 > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888434958%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=LXfycFoI2vtK9mkIgqt4ztjEipKPunPm8RlkbkrS1Zw%3D&reserved=0<https://datatracker.ietf/> > . > org_doc_draft-2Dwang-2Dhybrid-2Dkem-2Dikev2-2Dfrodo_&d=DwIGaQ&c=BSDicq > BQBDjDI9RkVyTcHQ&r=pgQajsQGPGHfcehiLJAf-Vgf2_A4DiT5oMtsz3qN40Y&m=Gceg8 > Al9Grbeyiphao9bC6ROOJXKrlXrbYseb8yxCDjlTmStNkuSL0m1jbJzvkku&s=1aNB7LAu > h7TKISDNJizzulUoe3nI-GH6jFUXDC3rcQI&e= > > > > Cheers, > > > > Guilin > > > > From:Bruckert, Leonie <leonie.bruck...@secunet.com> > > To:Wang Guilin <wang.gui...@huawei.com>;ipsec <ipsec@ietf.org> > > Date:2024-11-06 10:41:21 > > Subject:AW: [IPsec] Comments regarding > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > Hi Guilin, > > > > Thank you for your offer. I am looking forward to working together on this > draft. > > > > Cheers, > Leonie > > > > Von: Wang Guilin <wang.gui...@huawei.com> > Gesendet: Dienstag, 5. November 2024 15:06 > An: Bruckert, Leonie <leonie.bruck...@secunet.com>; ipsec > <ipsec@ietf.org> > Cc: Wang Guilin <wang.gui...@huawei.com> > Betreff: RE: [IPsec] Comments regarding > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > > Hi, Leonie, > > > > Thanks a lot for your detailed comments. > > > > A little later, I will integrate them into a new version. I am happy to > invite you working together on the draft. > > > > Cheers, > > > > Guilin > > > > ________________________________ > > > Wang Guilin > Mobile: +65-86920345 > Mail: wang.gui...@huawei.com > > From:Bruckert, Leonie <leonie.bruck...@secunet.com> > > To:ipsec <ipsec@ietf.org> > > Date:2024-11-05 12:15:37 > > Subject:[IPsec] Comments regarding > draft-wang-hybrid-kem-ikev2-frodo-02 > > > > I had a closer look at the Frodo draft. Please find my comments below. > > > > Cheers, > > Leonie > > > > General comments: > > - The terminology should be aligned throughout the whole document, e.g. Frodo > should be replaced by FrodoKEM. > > - I would add one or two sentences to the introduction like “This document > uses the terminology defined in “Terminology for Post-Quantum Traditional > Hybrid Schemes…” > > - I am wondering if it is sufficient to refer to the upcoming ISO standard or > the public FrodoKEM specification document, respectively. Do we want or need > a FrodoKEM specification from cfrg? > > - In general, I would recommend (but not require) to use FrodoKEM in addition > to the traditional key exchange, and also mention that it can be used > together with multiple PQ KEMs. > > - I found lots of typos, which I tried to correct in my text proposals, but > there are probably some more. > > > > Here are some specific comments mainly regarding abstract and introduction: > > > > Abstract: > > When RFC 9370 was written the main motivation was to do a PQC KEM in addition > to ECDH, but RFC 9370 does not require the first key exchange to be ECDH. In > principle, you could do a PQC KEM in the first exchange. So, I would rewrite > the Abstract (I also corrected a number of typos in the NEW text), e.g. > > > > --OLD-- > > RFC 9370 specifies a framework that supports mulitple key encapsulation > mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by > allowing up to 7 layers of additiona KEMs employed with the oringal ECDH to > derive the final shared secret keys for IPsec protocols. The primitive goal > is to mitigate the security threat against quantum computers by hybriding > additional post-quantum (PQ) KEMs with the orinigal ECDH key exchange. This > draft specifies how one QP KEMs, FrodoKEM, is instantiated in the IKEv2 as > the additional KEMs with the main ECDH to achieve hybrid key agreement. > > > > --NEW-- > > “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. 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 IKEv2 as an > additional key exchange mechanism. > > > > The link in the EDNOTE points to the wrong draft (terminology draft). > > > > Introduction: > > Some sentences are quite long and complex, so I tried to simplify a bit > (again correcting typos). Here are my suggestions: > > > > --OLD-- > > To mitigate the security threats on key exchanges again quantum computers, > especialy the harvest-now-and-decrypt-later (HNDL) attack, the approach of > hybrid key encapsulation mechanisms (KEMs) has been proposed to achieve > secure key exchange if at least one of KEMs is still secure. In particular, > hybrid KEMs is supposed to be used in the scenarios where one or multiple > traditional KEMs are used together with one or multiple post-quantum KEMs > [I-D.D24]. The Internet Key Exchange Protocol Version 2 (IKEv2), which > sepecifies the key exchange procedures of IPSec, has to be updated for > quantum resistant security. For this purpose, RFC 9370 [RFC9370] describes a > framework to hybrid mulitple key encapsulation mechanisms (KEMs), which > extends the IKEv2 by allowing multiple key exchanges to take place for > deriving shared secret keys during a Security Association (SA) setup. > Essentially, this speficiation employs the IKE_INTERMEDIATE exchange, which > is a new IKE message introduced in [RFC9242] so that multiple key exchanges > can be run to establish an IKE SA via exchanging additional PQ public keys > and ciphertexts between a client and a server. RFC 9370 also introduces > IKE_FOLLOWUP_KE, a new IKEv2 exchange for realizing the same purpose when the > IKE SA is being rekeyed or is creating additional Child SAs. > > > > --NEW-- > > Cryptographically-relevant quantum computers pose a threat to > cryptographically protected data. In particular, the so-called > harvest-now-and-decrypt-later (HNDL) attack is considered an imminent threat. > To mitigate this threat the concept of hybrid key encapsulation mechanisms > (KEMs) has been proposed to achieve secure key exchange if at least one of > the KEMs is still secure. “Multiple key exchanges in the Internet Key > Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framework to > perform hybrid key encapsulation in IKEv2 by allowing multiple key exchanges > to take place for deriving shared secret keys during a Security Association > (SA) setup. Essentially, this specification employs the IKE_INTERMEDIATE > exchange, which is a new IKEv2 message introduced in “Intermediate Exchange > in the Internet Key Exchange Protocol Version 2 (IKEv2)” [RFC9242], so that > multiple key exchanges can be run to establish an IKE SA via exchanging > additional PQ public keys and ciphertexts between a client and a server. RFC > 9370 also introduces IKE_FOLLOWUP_KE, a new IKEv2 exchange for realizing the > same purpose when the IKE SA is being rekeyed or additional Child SAs are > created. > > > > > > --OLD-- > > However, RFC 9370 just specifies the framework of hybrid KEMS but it has not > been instantiated for concrete multiple KEMS. [I-D.KR24] desribes how the > framework given by RFC 9370 can be run with the post-quantum (PQ) ML-KEM > [FIPS203], previously called Kyber, which is the standard published by NIST > in August of 2024. However, on the one hand, FRC 9350 allows up to 7 layers > of additiona KEMs employed with the oringal ECDH to derive final shared > secret keys for the IKEv2. On the other hand, for some applications (e.g. > financial services) demanding high security level, additional PQ KEMs may be > desired for completing the hybrid KEMs for the IKEv2. Currently, ISO is now > standardizing three PQ KEM aglorithms: Kyber, FrodoKEM, and classic > McElliece. Note that Frodo [Frodo] is unstructured lattice based KEM, whose > security is more conservative compared to ML-KEM, which is based on > structured lattice. Therefore, this draft is motivated to describe concretely > how the frame of hybrid KEMs for the IKEv2 specified in RFC 9370 can be run > via hybriding the ogirinal ECDH and FrodoKEM, even with ML-KEM together, if > necessary. > > > > --NEW-- > > However, RFC 9370 just specifies the framework of hybrid KEMS and has to be > been instantiated for concrete KEMS by separate documents. [I-D.KR24] > describes how the framework given by RFC 9370 can be run with the ML-KEM > [FIPS203], previously called Kyber. which has been standardized by NIST in > August 2024. However, on the one hand, RFC 9350 allows up to 7 layers of > additional KEMs to derive final shared secret keys for the IKEv2. On the > other hand, for some applications (e.g. financial services) demanding high > security level, additional PQ KEMs may be desired for use with RFC 9370. > Currently, ISO is standardizing three PQ KEM algorithms (EDNOTE: we may want > to change the wording since the ISO standard will be finished eventually): > Kyber, FrodoKEM, and Classic McEliece. Note that FrodoKEM [Frodo] is > unstructured lattice based KEM, whose security is more conservative compared > to ML-KEM, which is based on structured lattice. Therefore, this draft is > motivated to describe concretely how the frame of hybrid KEMs for the IKEv2 > specified in RFC 9370 can be instantiated with FrodoKEM. FrodoKEM should be > used together with a traditional key exchange mechanism such as ECDH and in > addition, may be used with further KEMs e.g. ML-KEM. > > > > > > Further issues in introduction: > > - Second bullet point: Add a reference for the break of SIKE > > - typos in last paragraph: performace -> performance, triger -> > trigger > > > > > > More typos: > > - section 3, last paragraph: > stardandization -> standardization > performace -> performance > showen -> shown > roughtly -> roughly > triger -> trigger > > > > > > > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ CFRG mailing list -- c...@irtf.org To unsubscribe send an email to cfrg-le...@irtf.org
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
