On Thu, 23 Jan 2025 at 10:11, John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> wrote: > > >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 This makes sense.
> > >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 > > > > > > > > > > > > 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 _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
