Do we know which transform IDs will be used for the pre-standard PQCs (FrodoKEM, BIKE, HQC)?
Thanks Phil On Wed, Jan 22, 2025 at 10:46 AM Watson Ladd <watsonbl...@gmail.com> wrote: > 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dwang-2Dhybrid-2Dkem-2Dikev2-2Dfrodo_&d=DwIGaQ&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=fi0Vudjp7ZG0vZu5L5OeeHaXSgmYikVWtQNTHRgHwrw&m=5LQXox8QmSL-AWvRaf0j7rgg6ROW0Sz4GoTvP_U2mgcDQEnoycEO3kayt4Ltf94V&s=p4VQxrO4qEcUfi47flqvqPIKvOZo7l8JSVai-1_WjeU&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 > > > > > > > > > > > > > > > > _______________________________________________ > > 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 >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
