>There are a number of updates to government guidance in the works. I am aware and I am looking forward to these. Current public documentation and presentations from European countries has been very useful, especially documents co-authored by several countries like this https://www.forsvarsmakten.se/contentassets/f7199ed1b90f41529b76970bdb5fce1c/position-paper-on-quantum-key-distribution.pdf I would like to see more such documents.
>I may speak to a different cohort than you, but the shift that I notice is >nuanced in “recommended” vs “allowed”. Not sure how much this >matters – just >wanted to tell you what I see. Thanks, I have not noticed that change in nuance except from The Netherlands. Important to remember that there are many European countries and that they do not agree on everything. The best thing would be if representatives for the European countries could speak up so we don’t have to speculate. They are probably all on this list… Cheers, John From: Michael Osborne <o...@zurich.ibm.com> Date: Thursday, 23 January 2025 at 09:25 To: John Mattsson <john.matts...@ericsson.com>, Loganaden Velvindron <logana...@gmail.com> Cc: Wang Guilin <wang.gui...@huawei.com>, ipsec <ipsec@ietf.org>, cfrg <c...@irtf.org> Subject: RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 Hi John “My current understanding is that many European governments are planning to use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral key exchange for their national security systems” This is not the sentiment that I am picking up – perhaps I speak to different government clients. This was certainly the case before the NIST algorithms were standardized but the wind seems to have shifted. There are a number of updates to government guidance in the works. These have been triggered by completion of the NIST standards. I may speak to a different cohort than you, but the shift that I notice is nuanced in “recommended” vs “allowed”. Not sure how much this matters – just wanted to tell you what I see. Regards Mike From: John Mattsson <john.matts...@ericsson.com> Sent: Thursday, January 23, 2025 7:29 AM To: Michael Osborne <o...@zurich.ibm.com>; Loganaden Velvindron <logana...@gmail.com> Cc: Wang Guilin <wang.gui...@huawei.com>; ipsec <ipsec@ietf.org>; cfrg <c...@irtf.org> Subject: [EXTERNAL] Re: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their list of recommended algorithms, which I very much welcome, but I have not seen any indication that they would stop recommending FrodoKEM. My current understanding is that ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their list of recommended algorithms, which I very much welcome, but I have not seen any indication that they would stop recommending FrodoKEM. My current understanding is that many European governments are planning to use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral key exchange for their national security systems. Like the US more algorithms might be allowed for government systems that are not national security systems. https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_stephan-ehlen_bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_jerome-plut_anssi_anssi-plan-for-post-quantum-transition.pdf https://cyber.gouv.fr/sites/default/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf https://cyber.gouv.fr/sites/default/files/document/pqc-transition-in-france.pdf http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf John From: Michael Osborne <o...@zurich.ibm.com<mailto:o...@zurich.ibm.com>> Date: Wednesday, 22 January 2025 at 20:39 To: Loganaden Velvindron <logana...@gmail.com<mailto:logana...@gmail.com>>, John Mattsson <john.matts...@ericsson.com<mailto:john.matts...@ericsson.com>> Cc: Wang Guilin <wang.gui...@huawei.com<mailto:wang.gui...@huawei.com>>, ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>>, cfrg <c...@irtf.org<mailto:c...@irtf.org>>, Wang Guilin <wang.gui...@huawei.com<mailto:wang.gui...@huawei.com>> Subject: RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2 [You don't often get email from o...@zurich.ibm.com<mailto:o...@zurich.ibm.com>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] 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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublications.tno.nl%2Fpublication%2F34643386%2FfXcPVHsX%2FTNO-2024-pqc-en.pdf&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888408248%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=d0eSQESgqm9ntxphpjmg2KriyCA5TxBlBI19VkpYJaY%3D&reserved=0<https://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.pdf> I understand BSI Germany and others will do the same shortly Kind Regards Mike -----Original Message----- From: Loganaden Velvindron <logana...@gmail.com<mailto:logana...@gmail.com>> Sent: Wednesday, January 22, 2025 7:11 PM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:john.mattsson=40ericsson....@dmarc.ietf.org>> Cc: Wang Guilin <Wang.Guilin=40huawei....@dmarc.ietf.org<mailto:Wang.Guilin=40huawei....@dmarc.ietf.org>>; ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>>; cfrg <c...@irtf.org<mailto:c...@irtf.org>>; Wang Guilin <wang.gui...@huawei.com<mailto: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<mailto: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://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.wolfssl.com%2Fcoming-soon-frodokem-in-wolfcrypt%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888424244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=tZbHySbq7mntNnFNM7sEXxmBTvQ9G3LQgbJ9Zs0jp2Y%3D&reserved=0<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<mailto:Wang.Guilin=40huawei....@dmarc.ietf.org>> > Date: Wednesday, 6 November 2024 at 15:22 > To: plonga <plo...@microsoft.com<mailto:plo...@microsoft.com>> > Cc: ipsec <ipsec@ietf.org<mailto:ipsec@ietf.org>>, cfrg > <c...@irtf.org<mailto:c...@irtf.org>>, Wang Guilin > <wang.gui...@huawei.com<mailto: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%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888434958%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=LXfycFoI2vtK9mkIgqt4ztjEipKPunPm8RlkbkrS1Zw%3D&reserved=0<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<mailto:leonie.bruck...@secunet.com>> > > To:Wang Guilin <wang.gui...@huawei.com<mailto:wang.gui...@huawei.com>>;ipsec > <ipsec@ietf.org<mailto: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<mailto:wang.gui...@huawei.com>> > Gesendet: Dienstag, 5. November 2024 15:06 > An: Bruckert, Leonie > <leonie.bruck...@secunet.com<mailto:leonie.bruck...@secunet.com>>; ipsec > <ipsec@ietf.org<mailto:ipsec@ietf.org>> > Cc: Wang Guilin <wang.gui...@huawei.com<mailto: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<mailto:wang.gui...@huawei.com> > > From:Bruckert, Leonie > <leonie.bruck...@secunet.com<mailto:leonie.bruck...@secunet.com>> > > To:ipsec <ipsec@ietf.org<mailto: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<mailto:ipsec@ietf.org> > To unsubscribe send an email to > ipsec-le...@ietf.org<mailto:ipsec-le...@ietf.org> _______________________________________________ CFRG mailing list -- c...@irtf.org<mailto:c...@irtf.org> To unsubscribe send an email to cfrg-le...@irtf.org<mailto:cfrg-le...@irtf.org>
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
