On Wed, Jan 22, 2025 at 5:07 AM 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.
The relevant registry is expert review, so you can just do that. > > > > 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-wang-hybrid-kem-ikev2-frodo/ > > > > 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 > > > > > > > > _______________________________________________ > CFRG mailing list -- c...@irtf.org > To unsubscribe send an email to cfrg-le...@irtf.org -- Astra mortemque praestare gradatim _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
