Thanks. I can also see that Classic Mceliece was also deemed as "acceptable".
Projects using it include Rosenpass, MullvadVPN, and my understanding is that Ericsson is also planning to adopt it ? Simon started working on an I-D for Classic MCeliece. On Wed, 22 Jan 2025 at 23:37, Michael Osborne <o...@zurich.ibm.com> wrote: > > 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://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.pdf > I understand BSI Germany and others will do the same shortly > Thanks. I can also see that Classic Mceliece was also deemed as "acceptable". > 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://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://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
