>There exist standards for FrodoKEM now, so you could point to those documents >(or does IANA insist they be IETF documents?) I do not think IETF should normatively refer to paywalled ISO crypto standards, they don’t even fulfill specification required. Paywalls significantly discourage security researchers from analyzing and reasoning about standards and their interactions. Open access is critical for security specifications, as history has repeatedly demonstrated that a lack of open discussion and thorough analysis often results in significant vulnerabilities. Paywalled standards also enable selective distribution of weakened standards to specific users, similar to the Swiss Crypto AG affair. Paywalled standards pose a significant cybersecurity risk.
I think the draft/RFC should be updated to the latest version on frodokem.org https://frodokem.org/files/FrodoKEM_standard_proposal_20241205.pdf >On the other hand, it is far too early for BIKE or HQC. For one, we don't >know which NIST would select. And, even when they do, >they may very well >make tweaks between now and when the final FIPS is issued. I suspect we'll >want to wait then before asking >for official code points. Yes, code points after FIPS or SP is published. Cheers, John From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> Date: Wednesday, 22 January 2025 at 18:26 To: Watson Ladd <watsonbl...@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]: FrodoKEM and its usage in IKemEv2 There exist standards for FrodoKEM now, so you could point to those documents (or does IANA insist they be IETF documents?) On the other hand, it is far too early for BIKE or HQC. For one, we don't know which NIST would select. And, even when they do, they may very well make tweaks between now and when the final FIPS is issued. I suspect we'll want to wait then before asking for official code points. > -----Original Message----- > From: Watson Ladd <watsonbl...@gmail.com> > Sent: Wednesday, January 22, 2025 11:44 AM > 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: [CFRG] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 > > 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-wang-hybrid-kem-ikev2-frodo%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C3f84462ca9b347207fe508dd3b09f81a%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731636176404975%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=hx4vd5RZCkeH9nk7hIiUJGhJih7%2BZc%2BxvxxqvSKh5Lo%3D&reserved=0<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 > > _______________________________________________ > 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
