[CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKemEv2
John Mattsson <[email protected]> Thu, 23 Jan 2025 09:05:51 +0000
| Newsgroups | gmane.ietf.irtf.cfrg,gmane.ietf.ipsec |
|---|---|
| Message-ID | <GVXPR07MB96781CB198E9A29FEC817B8E89E02@GVXPR07MB9678.eurprd07.prod.outlook.com> |
--===============5623138276912692404== Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_GVXPR07MB96781CB198E9A29FEC817B8E89E02GVXPR07MB9678eurp_" --_000_GVXPR07MB96781CB198E9A29FEC817B8E89E02GVXPR07MB9678eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable >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/f7199ed1b90f41529b76970bdb5fce1= c/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 i= s nuanced in =93recommended=94 vs =93allowed=94. Not sure how much this >m= atters =96 just wanted to tell you what I see. Thanks, I have not noticed that change in nuance except from The Netherland= s. Important to remember that there are many European countries and that th= ey do not agree on everything. The best thing would be if representatives f= or the European countries could speak up so we don=92t have to speculate. T= hey are probably all on this list=85 Cheers, John From: Michael Osborne <[email protected]> Date: Thursday, 23 January 2025 at 09:25 To: John Mattsson <[email protected]>, Loganaden Velvindron <logan= [email protected]> Cc: Wang Guilin <[email protected]>, ipsec <[email protected]>, cfrg <cfr= [email protected]> Subject: RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKem= Ev2 Hi John =93My current understanding is that many European governments are planning = to use FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephem= eral key exchange for their national security systems=94 This is not the sentiment that I am picking up =96 perhaps I speak to diffe= rent government clients. This was certainly the case before the NIST algori= thms were standardized but the wind seems to have shifted. There are a number of updates to government guidance in the works. These h= ave 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 =93recommended=94 vs =93allowed=94. Not sure how much this mat= ters =96 just wanted to tell you what I see. Regards Mike From: John Mattsson <[email protected]> Sent: Thursday, January 23, 2025 7:29 AM To: Michael Osborne <[email protected]>; Loganaden Velvindron <loganaden@g= mail.com> Cc: Wang Guilin <[email protected]>; ipsec <[email protected]>; cfrg <cfr= [email protected]> Subject: [EXTERNAL] Re: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its us= age in IKemEv2 ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their l= ist of recommended algorithms, which I very much welcome, but I have not se= en any indication that they would stop recommending FrodoKEM. My current un= derstanding is that ANSSI, BSI, and Swedish NCSA have all just recently added ML-KEM to their l= ist of recommended algorithms, which I very much welcome, but I have not se= en any indication that they would stop recommending FrodoKEM. My current un= derstanding is that many European governments are planning to use FrodoKEM = as the main quantum-resistant algorithm for ephemeral-ephemeral key exchang= e 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-p= lut_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 <[email protected]<mailto:[email protected]>> Date: Wednesday, 22 January 2025 at 20:39 To: Loganaden Velvindron <[email protected]<mailto:[email protected]>>,= John Mattsson <[email protected]<mailto:[email protected]= m>> Cc: Wang Guilin <[email protected]<mailto:[email protected]>>, ip= sec <[email protected]<mailto:[email protected]>>, cfrg <[email protected]<mailto:cfr= [email protected]>>, Wang Guilin <[email protected]<mailto:Wang.Guilin@huawei= .com>> Subject: RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage in IKem= Ev2 [You don't often get email from [email protected]<mailto:[email protected]= m>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentific= ation ] Hi John You want to check this statement " Many European governments are planning t= o use FrodoKEM as the main quantum-resistant algorithm for ephemeral-epheme= ral key exchange" The Netherlands have already updated guidance such that ML-KEM is recommen= ded and FrodoKEM is acceptable. https://eur02.safelinks.protection.outlook.= com/?url=3Dhttps%3A%2F%2Fpublications.tno.nl%2Fpublication%2F34643386%2FfXc= PVHsX%2FTNO-2024-pqc-en.pdf&data=3D05%7C02%7Cjohn.mattsson%40ericsson.com%7= Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C= 0%7C638731715888408248%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYi= OiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C= %7C%7C&sdata=3Dd0eSQESgqm9ntxphpjmg2KriyCA5TxBlBI19VkpYJaY%3D&reserved=3D0<= https://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.p= df> I understand BSI Germany and others will do the same shortly Kind Regards Mike -----Original Message----- From: Loganaden Velvindron <[email protected]<mailto:[email protected]>= > Sent: Wednesday, January 22, 2025 7:11 PM To: John Mattsson <[email protected]<mailto:joh= [email protected]>> Cc: Wang Guilin <[email protected]<mailto:Wang.Guil= [email protected]>>; ipsec <[email protected]<mailto:ipsec@ietf= .org>>; cfrg <[email protected]<mailto:[email protected]>>; Wang Guilin <Wang.Guili= [email protected]<mailto:[email protected]>> 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=3D40ericsson.com= @dmarc.ietf.org<mailto:[email protected]>> wrot= e: > > Hi, > > > > I think IKEv2 should register code points for FrodoKEM and BIKE/HQC (depe= nding 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 cry= ptographic primitive to switch to. The practice of implementing cryptograph= ic backup algorithms has long been a guiding principle in the telecom indus= try. > Indeed. Cryptographic agility is good. I've also seen this from wolfssl: https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.wol= fssl.com%2Fcoming-soon-frodokem-in-wolfcrypt%2F&data=3D05%7C02%7Cjohn.matts= son%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe5= 2080c6b87953f%7C0%7C0%7C638731715888424244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0= eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo= yfQ%3D%3D%7C60000%7C%7C%7C&sdata=3DtZbHySbq7mntNnFNM7sEXxmBTvQ9G3LQgbJ9Zs0j= p2Y%3D&reserved=3D0<https://www.wolfssl.com/coming-soon-frodokem-in-wolfcry= pt/> > > > FrodoKEM is unstructuctured but still lattice, BIKE/HQC is code-based but= still structured. Many European governments are planning to use FrodoKEM a= s the main quantum-resistant algorithm for ephemeral-ephemeral key exchange= . For an ESP association sending 100 GB of data, the overhead of FrodoKEM a= nd BIKE/HQC is small. > > > > Classic McEliece could also be considered but I think it is mostly intere= sting for static encapsulation keys like in HPKE. > > > > I think CFRG should specify FrodoKEM, but I am also fine with continue us= ing frodokem.org as a normative reference. > > > > Cheers, > > John > > > > From: Wang Guilin <[email protected]<mailto:Wang.= [email protected]>> > Date: Wednesday, 6 November 2024 at 15:22 > To: plonga <[email protected]<mailto:[email protected]>> > Cc: ipsec <[email protected]<mailto:[email protected]>>, cfrg <[email protected]<ma= ilto:[email protected]>>, Wang Guilin > <[email protected]<mailto:[email protected]>> > Subject: [CFRG] [IPsec]: FrodoKEM and its usage in IKemEv2 > > Dear Patrick, > > > > As disccussed during your talk about FrodoKEM in the CFRG meeting, here i= s 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=3Dhttps%3A%2F%2Fdatat= racker.ietf%2F&data=3D05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e74= 4678b06708dd3b1c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715= 888434958%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwM= CIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata= =3DLXfycFoI2vtK9mkIgqt4ztjEipKPunPm8RlkbkrS1Zw%3D&reserved=3D0<https://data= tracker.ietf/> . > org_doc_draft-2Dwang-2Dhybrid-2Dkem-2Dikev2-2Dfrodo_&d=3DDwIGaQ&c=3DBSDic= q > BQBDjDI9RkVyTcHQ&r=3DpgQajsQGPGHfcehiLJAf-Vgf2_A4DiT5oMtsz3qN40Y&m=3DGceg= 8 > Al9Grbeyiphao9bC6ROOJXKrlXrbYseb8yxCDjlTmStNkuSL0m1jbJzvkku&s=3D1aNB7LAu > h7TKISDNJizzulUoe3nI-GH6jFUXDC3rcQI&e=3D > > > > Cheers, > > > > Guilin > > > > From:Bruckert, Leonie <[email protected]<mailto:Leonie.Bruckert= @secunet.com>> > > To:Wang Guilin <[email protected]<mailto:[email protected]>>;ip= sec <[email protected]<mailto:[email protected]>> > > 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 thi= s draft. > > > > Cheers, > Leonie > > > > Von: Wang Guilin <[email protected]<mailto:[email protected]>> > Gesendet: Dienstag, 5. November 2024 15:06 > An: Bruckert, Leonie <[email protected]<mailto:Leonie.Bruckert@= secunet.com>>; ipsec > <[email protected]<mailto:[email protected]>> > Cc: Wang Guilin <[email protected]<mailto:[email protected]>> > 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 i= nvite you working together on the draft. > > > > Cheers, > > > > Guilin > > > > ________________________________ > > > Wang Guilin > Mobile: +65-86920345 > Mail: [email protected]<mailto:[email protected]> > > From:Bruckert, Leonie <[email protected]<mailto:Leonie.Bruckert= @secunet.com>> > > To:ipsec <[email protected]<mailto:[email protected]>> > > 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. F= rodo should be replaced by FrodoKEM. > > - I would add one or two sentences to the introduction like =93This docum= ent uses the terminology defined in =93Terminology for Post-Quantum Traditi= onal Hybrid Schemes=85=94 > > - I am wondering if it is sufficient to refer to the upcoming ISO standar= d or the public FrodoKEM specification document, respectively. Do we want o= r need a FrodoKEM specification from cfrg? > > - In general, I would recommend (but not require) to use FrodoKEM in addi= tion 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, b= ut there are probably some more. > > > > Here are some specific comments mainly regarding abstract and introductio= n: > > > > Abstract: > > When RFC 9370 was written the main motivation was to do a PQC KEM in addi= tion to ECDH, but RFC 9370 does not require the first key exchange to be EC= DH. 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 m= echanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2) by= allowing up to 7 layers of additiona KEMs employed with the oringal ECDH t= o derive the final shared secret keys for IPsec protocols. The primitive go= al is to mitigate the security threat against quantum computers by hybridin= g additional post-quantum (PQ) KEMs with the orinigal ECDH key exchange. Th= is 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-- > > =93Multiple key exchanges in the Internet Key Exchange Protocol Version 2= (IKEv2) [RFC9370] specifies a framework that supports multiple key encapsu= lation mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (I= KEv2) by allowing up to 7 layers of additional KEMs to derive the final sha= red secret keys for IPsec protocols. The primary goal is to mitigate the = =93harvest now and decrypt later=94 threat posed by cryptanalytically-relev= ant quantum computers. For this purpose, usually one or more post-quantum K= EMs 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 o= f hybrid key encapsulation mechanisms (KEMs) has been proposed to achieve s= ecure 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 t= raditional KEMs are used together with one or multiple post-quantum KEMs [I= -D.D24]. The Internet Key Exchange Protocol Version 2 (IKEv2), which sepeci= fies the key exchange procedures of IPSec, has to be updated for quantum re= sistant security. For this purpose, RFC 9370 [RFC9370] describes a framewor= k 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 sp= eficiation employs the IKE_INTERMEDIATE exchange, which is a new IKE messag= e introduced in [RFC9242] so that multiple key exchanges can be run to esta= blish an IKE SA via exchanging additional PQ public keys and ciphertexts be= tween a client and a server. RFC 9370 also introduces IKE_FOLLOWUP_KE, a ne= w IKEv2 exchange for realizing the same purpose when the IKE SA is being re= keyed or is creating additional Child SAs. > > > > --NEW-- > > Cryptographically-relevant quantum computers pose a threat to cryptograph= ically protected data. In particular, the so-called harvest-now-and-decrypt= -later (HNDL) attack is considered an imminent threat. To mitigate this thr= eat the concept of hybrid key encapsulation mechanisms (KEMs) has been prop= osed to achieve secure key exchange if at least one of the KEMs is still se= cure. =93Multiple key exchanges in the Internet Key Exchange Protocol Versi= on 2 (IKEv2) [RFC9370] specifies a framework to perform hybrid key encapsul= ation in IKEv2 by allowing multiple key exchanges to take place for derivin= g shared secret keys during a Security Association (SA) setup. Essentially,= this specification employs the IKE_INTERMEDIATE exchange, which is a new I= KEv2 message introduced in =93Intermediate Exchange in the Internet Key Exc= hange Protocol Version 2 (IKEv2)=94 [RFC9242], so that multiple key exchang= es can be run to establish an IKE SA via exchanging additional PQ public ke= ys 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 t= he 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 t= he 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 NIS= T in August of 2024. However, on the one hand, FRC 9350 allows up to 7 laye= rs 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. f= inancial services) demanding high security level, additional PQ KEMs may be= desired for completing the hybrid KEMs for the IKEv2. Currently, ISO is no= w standardizing three PQ KEM aglorithms: Kyber, FrodoKEM, and classic McEll= iece. Note that Frodo [Frodo] is unstructured lattice based KEM, whose secu= rity 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 hyb= riding the ogirinal ECDH and FrodoKEM, even with ML-KEM together, if necess= ary. > > > > --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] de= scribes how the framework given by RFC 9370 can be run with the ML-KEM [FIP= S203], previously called Kyber. which has been standardized by NIST in Augu= st 2024. However, on the one hand, RFC 9350 allows up to 7 layers of additi= onal KEMs to derive final shared secret keys for the IKEv2. On the other ha= nd, 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 chang= e the wording since the ISO standard will be finished eventually): Kyber, F= rodoKEM, and Classic McEliece. Note that FrodoKEM [Frodo] is unstructured l= attice based KEM, whose security is more conservative compared to ML-KEM, w= hich 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 togeth= er 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 -- [email protected]<mailto:[email protected]> > To unsubscribe send an email to [email protected]<mailto:ipsec-leave@i= etf.org> _______________________________________________ CFRG mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:cfrg-leave@irtf.= org> --_000_GVXPR07MB96781CB198E9A29FEC817B8E89E02GVXPR07MB9678eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1= 252"> <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style><!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} @font-face {font-family:Aptos; panose-1:2 11 0 4 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; font-size:12.0pt; font-family:"Aptos",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} span.EmailStyle20 {mso-style-type:personal-reply; font-family:"Aptos",sans-serif; color:windowtext;} .MsoChpDefault {mso-style-type:export-only; font-size:10.0pt; mso-ligatures:none;} @page WordSection1 {size:612.0pt 792.0pt; margin:72.0pt 72.0pt 72.0pt 72.0pt;} div.WordSection1 {page:WordSection1;} --></style> </head> <body lang=3D"en-SE" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea= k-word"> <div class=3D"WordSection1"> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">>= There are a number of updates to government guidance in the works.<br> 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<br> <a href=3D"https://www.forsvarsmakten.se/contentassets/f7199ed1b90f41529b76= 970bdb5fce1c/position-paper-on-quantum-key-distribution.pdf">https://www.fo= rsvarsmakten.se/contentassets/f7199ed1b90f41529b76970bdb5fce1c/position-pap= er-on-quantum-key-distribution.pdf</a> <br> I would like to see more such documents.<br> <br> >I may speak to a different cohort than you, but the shift that I = notice is nuanced in =93recommended=94 vs =93allowed=94. Not sure how= much this >matters =96 just wanted to tell you what I see.</span><span = lang=3D"EN-US" style=3D"font-size:11.0pt;mso-fareast-language:EN-US"><br> Thanks, I have not </span><span lang=3D"EN-US" style=3D"font-size:11.0pt">n= oticed that change in nuance except from The Netherlands. Important to reme= mber that there are many European countries and that they do not agree on e= verything. </span><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-fareast-language:= EN-US">The best thing would be if representatives for the European countrie= s could speak up so we don=92t have to speculate. They are probably all on = this list=85</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><br> Cheers,<br> John<o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt;mso-f= areast-language:EN-US"><o:p> </o:p></span></p> <div id=3D"mail-editor-reference-message-container"> <div> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span lang=3D"EN-U= S" style=3D"color:black">From: </span></b><span lang=3D"EN-US" style=3D"color:black">Michael Osborne <o= [email protected]><br> <b>Date: </b>Thursday, 23 January 2025 at 09:25<br> <b>To: </b>John Mattsson <[email protected]>, Loganaden Velv= indron <[email protected]><br> <b>Cc: </b>Wang Guilin <[email protected]>, ipsec <ipsec@ietf= .org>, cfrg <[email protected]><br> <b>Subject: </b>RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage = in IKemEv2<o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Hi J= ohn</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">=93M= y current understanding is that many European governments are planning to u= se FrodoKEM as the main quantum-resistant algorithm for ephemeral-ephemeral= key exchange for their national security systems=94</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">This= is not the sentiment that I am picking up =96 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. </span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Ther= e are a number of updates to government guidance in the works. These = have been triggered by completion of the NIST standards.</span><span lang= =3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">I ma= y speak to a different cohort than you, but the shift that I notice i= s nuanced in =93recommended=94 vs =93allowed=94. Not sure how much th= is matters =96 just wanted to tell you what I see.</span><span lang=3D"EN-U= S"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Rega= rds</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">Mike= </span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <div style=3D"border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal"><b><span lang=3D"EN-US" style=3D"font-size:11.0pt;fo= nt-family:"Calibri",sans-serif">From:</span></b><span lang=3D"EN-= US" style=3D"font-size:11.0pt;font-family:"Calibri",sans-serif"> = John Mattsson <[email protected]> <br> <b>Sent:</b> Thursday, January 23, 2025 7:29 AM<br> <b>To:</b> Michael Osborne <[email protected]>; Loganaden Velvindron= <[email protected]><br> <b>Cc:</b> Wang Guilin <[email protected]>; ipsec <ipsec@ietf= .org>; cfrg <[email protected]><br> <b>Subject:</b> [EXTERNAL] Re: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and= its usage in IKemEv2</span><span lang=3D"EN-US"><o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US"> <o:p></o:p></span></p> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:1.0pt;color:= white">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</span><span l= ang=3D"EN-US"><o:p></o:p></span></p> </div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">ANSS= I, 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 a= ny indication that they would stop recommending FrodoKEM. My current understanding is that many European governments are p= lanning to use FrodoKEM as the main quantum-resistant algorithm for ephemer= al-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.</span><span= lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><br> <a href=3D"https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pq= cc_stephan-ehlen_bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf">https:= //pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_stephan-ehlen_= bsi_post-quantum-policy-and-roadmap-of-the-bsi.pdf</a></span><span lang=3D"= EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><a h= ref=3D"https://pkic.org/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_j= erome-plut_anssi_anssi-plan-for-post-quantum-transition.pdf">https://pkic.o= rg/events/2023/pqc-conference-amsterdam-nl/pkic-pqcc_jerome-plut_anssi_anss= i-plan-for-post-quantum-transition.pdf</a></span><span lang=3D"EN-US"><o:p>= </o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><a h= ref=3D"https://cyber.gouv.fr/sites/default/files/document/follow_up_positio= n_paper_on_post_quantum_cryptography.pdf">https://cyber.gouv.fr/sites/defau= lt/files/document/follow_up_position_paper_on_post_quantum_cryptography.pdf= </a></span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><a h= ref=3D"https://cyber.gouv.fr/sites/default/files/document/pqc-transition-in= -france.pdf">https://cyber.gouv.fr/sites/default/files/document/pqc-transit= ion-in-france.pdf</a></span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt"><a h= ref=3D"http://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf">h= ttp://kth.diva-portal.org/smash/get/diva2:1902626/FULLTEXT01.pdf</a></span>= <span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"SV" style=3D"font-size:11.0pt">John</s= pan><span lang=3D"EN-US"><o:p></o:p></span></p> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">&nbs= p;</span><span lang=3D"EN-US"><o:p></o:p></span></p> <div id=3D"mail-editor-reference-message-container"> <div> <div> <div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm = 0cm 0cm"> <p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span lang=3D"EN-U= S" style=3D"color:black">From: </span></b><span lang=3D"EN-US" style=3D"color:black">Michael Osborne <<= a href=3D"mailto:[email protected]">[email protected]</a>><br> <b>Date: </b>Wednesday, 22 January 2025 at 20:39<br> <b>To: </b>Loganaden Velvindron <<a href=3D"mailto:[email protected]">= [email protected]</a>>, John Mattsson <<a href=3D"mailto:john.matts= [email protected]">[email protected]</a>><br> <b>Cc: </b>Wang Guilin <<a href=3D"mailto:[email protected]">Wang.G= [email protected]</a>>, ipsec <<a href=3D"mailto:[email protected]">ipsec= @ietf.org</a>>, cfrg <<a href=3D"mailto:[email protected]">[email protected]<= /a>>, Wang Guilin <<a href=3D"mailto:[email protected]">Wang.Gui= [email protected]</a>><br> <b>Subject: </b>RE: [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage = in IKemEv2</span><span lang=3D"EN-US"><o:p></o:p></span></p> </div> <div> <p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"font-size:11.0pt">[You= don't often get email from <a href=3D"mailto:[email protected]">[email protected]</a>. Learn why thi= s is important at <a href=3D"https://aka.ms/LearnAboutSenderIdentification">https://aka.ms/Le= arnAboutSenderIdentification</a> ]<br> <br> Hi John<br> <br> You want to check this statement " Many European governments are plann= ing to use FrodoKEM as the main quantum-resistant algorithm for ephemeral-e= phemeral key exchange"<br> <br> The Netherlands have already updated guidance such that ML-KEM is rec= ommended and FrodoKEM is acceptable. <a href=3D"https://publications.tno.nl/publication/34643386/fXcPVHsX/TNO-20= 24-pqc-en.pdf"> https://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fpublica= tions.tno.nl%2Fpublication%2F34643386%2FfXcPVHsX%2FTNO-2024-pqc-en.pdf&= data=3D05%7C02%7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1= c521e%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888408248%7CUnk= nown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4z= MiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=3Dd0eSQESgq= m9ntxphpjmg2KriyCA5TxBlBI19VkpYJaY%3D&reserved=3D0</a><br> I understand BSI Germany and others will do the same shortly<br> <br> Kind Regards<br> <br> Mike<br> <br> -----Original Message-----<br> From: Loganaden Velvindron <<a href=3D"mailto:[email protected]">logan= [email protected]</a>><br> Sent: Wednesday, January 22, 2025 7:11 PM<br> To: John Mattsson <<a href=3D"mailto:john.mattsson=3D40ericsson.com@dmar= c.ietf.org">[email protected]</a>><br> Cc: Wang Guilin <<a href=3D"mailto:[email protected]= .org">[email protected]</a>>; ipsec <<a href= =3D"mailto:[email protected]">[email protected]</a>>; cfrg <<a href=3D"mail= to:[email protected]">[email protected]</a>>; Wang Guilin <<a href=3D"mailto:= [email protected]">[email protected]</a>><br> Subject: [EXTERNAL] [CFRG] Re: [IPsec] Re: [IPsec]: FrodoKEM and its usage = in IKemEv2<br> <br> On Wed, 22 Jan 2025 at 17:05, John Mattsson <<a href=3D"mailto:john.matt= [email protected]">john.mattsson=3D40ericsson.com@dmarc.= ietf.org</a>> wrote:<br> ><br> > Hi,<br> ><br> ><br> ><br> > I think IKEv2 should register code points for FrodoKEM and BIKE/HQC (d= epending on which one NIST standardizes). I think it is important with back= ups 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 t= o. The practice of implementing cryptographic backup algorithms has long be= en a guiding principle in the telecom industry.<br> ><br> Indeed. Cryptographic agility is good. I've also seen this from wolfssl:<br= > <br> <a href=3D"https://www.wolfssl.com/coming-soon-frodokem-in-wolfcrypt/">http= s://eur02.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.wolfssl= .com%2Fcoming-soon-frodokem-in-wolfcrypt%2F&data=3D05%7C02%7Cjohn.matts= son%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84cebfbfd47abbe5= 2080c6b87953f%7C0%7C0%7C638731715888424244%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0= eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjo= yfQ%3D%3D%7C60000%7C%7C%7C&sdata=3DtZbHySbq7mntNnFNM7sEXxmBTvQ9G3LQgbJ9= Zs0jp2Y%3D&reserved=3D0</a><br> <br> <br> <br> ><br> ><br> > FrodoKEM is unstructuctured but still lattice, BIKE/HQC is code-based = but still structured. Many European governments are planning to use FrodoKE= M as the main quantum-resistant algorithm for ephemeral-ephemeral key excha= nge. For an ESP association sending 100 GB of data, the overhead of FrodoKEM and BIKE/HQC is small.<br> ><br> ><br> ><br> > Classic McEliece could also be considered but I think it is mostly int= eresting for static encapsulation keys like in HPKE.<br> ><br> ><br> ><br> > I think CFRG should specify FrodoKEM, but I am also fine with continue= using frodokem.org as a normative reference.<br> ><br> ><br> ><br> > Cheers,<br> ><br> > John<br> ><br> ><br> ><br> > From: Wang Guilin <<a href=3D"mailto:Wang.Guilin=3D40huawei.com@dma= rc.ietf.org">[email protected]</a>><br> > Date: Wednesday, 6 November 2024 at 15:22<br> > To: plonga <<a href=3D"mailto:[email protected]">plonga@microsof= t.com</a>><br> > Cc: ipsec <<a href=3D"mailto:[email protected]">[email protected]</a>>= , cfrg <<a href=3D"mailto:[email protected]">[email protected]</a>>, Wang Gui= lin<br> > <<a href=3D"mailto:[email protected]">[email protected]</= a>><br> > Subject: [CFRG] [IPsec]: FrodoKEM and its usage in IKemEv2<br> ><br> > Dear Patrick,<br> ><br> ><br> ><br> > As disccussed during your talk about FrodoKEM in the CFRG meeting, her= e is the info about our draft.<br> ><br> ><br> ><br> > Post-quantum Hybrid Key Exchange in the IKEv2 with FrodoKEM<br> ><br> > draft-wang-hybrid-kem-ikev2-frodo-02<br> ><br> > <a href=3D"https://datatracker.ietf/">https://eur02.safelinks.protecti= on.outlook.com/?url=3Dhttps%3A%2F%2Fdatatracker.ietf%2F&data=3D05%7C02%= 7Cjohn.mattsson%40ericsson.com%7Ce33073792e744678b06708dd3b1c521e%7C92e84ce= bfbfd47abbe52080c6b87953f%7C0%7C0%7C638731715888434958%7CUnknown%7CTWFpbGZs= b3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWF= pbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=3DLXfycFoI2vtK9mkIgqt4ztjE= ipKPunPm8RlkbkrS1Zw%3D&reserved=3D0</a> .<br> > org_doc_draft-2Dwang-2Dhybrid-2Dkem-2Dikev2-2Dfrodo_&d=3DDwIGaQ&am= p;c=3DBSDicq<br> > BQBDjDI9RkVyTcHQ&r=3DpgQajsQGPGHfcehiLJAf-Vgf2_A4DiT5oMtsz3qN40Y&a= mp;m=3DGceg8<br> > Al9Grbeyiphao9bC6ROOJXKrlXrbYseb8yxCDjlTmStNkuSL0m1jbJzvkku&s=3D1a= NB7LAu<br> > h7TKISDNJizzulUoe3nI-GH6jFUXDC3rcQI&e=3D<br> ><br> ><br> ><br> > Cheers,<br> ><br> ><br> ><br> > Guilin<br> ><br> ><br> ><br> > From:Bruckert, Leonie <<a href=3D"mailto:[email protected]= m">[email protected]</a>><br> ><br> > To:Wang Guilin <<a href=3D"mailto:[email protected]">Wang.Guil= [email protected]</a>>;ipsec <<a href=3D"mailto:[email protected]">ipsec@iet= f.org</a>><br> ><br> > Date:2024-11-06 10:41:21<br> ><br> > Subject:AW: [IPsec] Comments regarding<br> > draft-wang-hybrid-kem-ikev2-frodo-02<br> ><br> ><br> ><br> > Hi Guilin,<br> ><br> ><br> ><br> > Thank you for your offer. I am looking forward to working together on = this draft.<br> ><br> ><br> ><br> > Cheers,<br> > Leonie<br> ><br> ><br> ><br> > Von: Wang Guilin <<a href=3D"mailto:[email protected]">Wang.Gu= [email protected]</a>><br> > Gesendet: Dienstag, 5. November 2024 15:06<br> > An: Bruckert, Leonie <<a href=3D"mailto:[email protected]= ">[email protected]</a>>; ipsec<br> > <<a href=3D"mailto:[email protected]">[email protected]</a>><br> > Cc: Wang Guilin <<a href=3D"mailto:[email protected]">Wang.Gui= [email protected]</a>><br> > Betreff: RE: [IPsec] Comments regarding<br> > draft-wang-hybrid-kem-ikev2-frodo-02<br> ><br> ><br> ><br> ><br> > Hi, Leonie,<br> ><br> ><br> ><br> > Thanks a lot for your detailed comments.<br> ><br> ><br> ><br> > A little later, I will integrate them into a new version. I am happy t= o invite you working together on the draft.<br> ><br> ><br> ><br> > Cheers,<br> ><br> ><br> ><br> > Guilin<br> ><br> ><br> ><br> > ________________________________<br> ><br> ><br> > Wang Guilin<br> > Mobile: +65-86920345<br> > Mail: <a href=3D"mailto:[email protected]">[email protected]= </a><br> ><br> > From:Bruckert, Leonie <<a href=3D"mailto:[email protected]= m">[email protected]</a>><br> ><br> > To:ipsec <<a href=3D"mailto:[email protected]">[email protected]</a>><= br> ><br> > Date:2024-11-05 12:15:37<br> ><br> > Subject:[IPsec] Comments regarding<br> > draft-wang-hybrid-kem-ikev2-frodo-02<br> ><br> ><br> ><br> > I had a closer look at the Frodo draft. Please find my comments below.= <br> ><br> ><br> ><br> > Cheers,<br> ><br> > Leonie<br> ><br> ><br> ><br> > General comments:<br> ><br> > - The terminology should be aligned throughout the whole document, e.g= . Frodo should be replaced by FrodoKEM.<br> ><br> > - I would add one or two sentences to the introduction like =93This do= cument uses the terminology defined in =93Terminology for Post-Quantum Trad= itional Hybrid Schemes=85=94<br> ><br> > - I am wondering if it is sufficient to refer to the upcoming ISO stan= dard or the public FrodoKEM specification document, respectively. Do we wan= t or need a FrodoKEM specification from cfrg?<br> ><br> > - In general, I would recommend (but not require) to use FrodoKEM in a= ddition to the traditional key exchange, and also mention that it can be us= ed together with multiple PQ KEMs.<br> ><br> > - I found lots of typos, which I tried to correct in my text proposals= , but there are probably some more.<br> ><br> ><br> ><br> > Here are some specific comments mainly regarding abstract and introduc= tion:<br> ><br> ><br> ><br> > Abstract:<br> ><br> > When RFC 9370 was written the main motivation was to do a PQC KEM in a= ddition 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 wo= uld rewrite the Abstract (I also corrected a number of typos in the NEW text), e.g.<br> ><br> ><br> ><br> > --OLD--<br> ><br> > RFC 9370 specifies a framework that supports mulitple key encapsulatio= n mechanisms (KEMs) in the Internet Key Exchange Protocol Version 2 (IKEv2)= by allowing up to 7 layers of additiona KEMs employed with the oringal ECD= H to derive the final shared secret keys for IPsec protocols. The primitive goal is to mitigate the security t= hreat against quantum computers by hybriding additional post-quantum (PQ) K= EMs with the orinigal ECDH key exchange. This draft specifies how one QP KE= Ms, FrodoKEM, is instantiated in the IKEv2 as the additional KEMs with the main ECDH to achieve hybrid key = agreement.<br> ><br> ><br> ><br> > --NEW--<br> ><br> > =93Multiple key exchanges in the Internet Key Exchange Protocol Versio= n 2 (IKEv2) [RFC9370] specifies a framework that supports multiple key enca= psulation 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 =93harvest now and decrypt later=94 t= hreat posed by cryptanalytically-relevant quantum computers. For this purpo= se, usually one or more post-quantum KEMs are performed in addition to the traditional (EC)DH key exchange. Thi= s draft specifies how the post-quantum KEM FrodoKEM is instantiated in IKEv= 2 as an additional key exchange mechanism.<br> ><br> ><br> ><br> > The link in the EDNOTE points to the wrong draft (terminology draft).<= br> ><br> ><br> ><br> > Introduction:<br> ><br> > Some sentences are quite long and complex, so I tried to simplify a bi= t (again correcting typos). Here are my suggestions:<br> ><br> ><br> ><br> > --OLD--<br> ><br> > To mitigate the security threats on key exchanges again quantum comput= ers, especialy the harvest-now-and-decrypt-later (HNDL) attack, the approac= h of hybrid key encapsulation mechanisms (KEMs) has been proposed to achiev= e 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 qua= ntum resistant security. For this purpose, RFC 9370 [RFC9370] describes a f= ramework to hybrid mulitple key encapsulation mechanisms (KEMs), which exte= nds the IKEv2 by allowing multiple key exchanges to take place for deriving shared secret keys during a Secur= ity Association (SA) setup. Essentially, this speficiation employs the IKE_= INTERMEDIATE exchange, which is a new IKE message introduced in [RFC9242] s= o 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_FO= LLOWUP_KE, a new IKEv2 exchange for realizing the same purpose when the IKE= SA is being rekeyed or is creating additional Child SAs.<br> ><br> ><br> ><br> > --NEW--<br> ><br> > Cryptographically-relevant quantum computers pose a threat to cryptogr= aphically protected data. In particular, the so-called harvest-now-and-decr= ypt-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 l= east one of the KEMs is still secure. =93Multiple key exchanges in the Inte= rnet Key Exchange Protocol Version 2 (IKEv2) [RFC9370] specifies a framewor= k to perform hybrid key encapsulation in IKEv2 by allowing multiple key exchanges to take place for deriving sha= red secret keys during a Security Association (SA) setup. Essentially, this= specification employs the IKE_INTERMEDIATE exchange, which is a new IKEv2 = message introduced in =93Intermediate Exchange in the Internet Key Exchange Protocol Version 2 (IKEv2)=94 [RFC92= 42], so that multiple key exchanges can be run to establish an IKE SA via e= xchanging 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 bei= ng rekeyed or additional Child SAs are created.<br> ><br> ><br> ><br> ><br> ><br> > --OLD--<br> ><br> > However, RFC 9370 just specifies the framework of hybrid KEMS but it h= as not been instantiated for concrete multiple KEMS. [I-D.KR24] desribes ho= w 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 t= he oringal ECDH to derive final shared secret keys for the IKEv2. On the ot= her hand, for some applications (e.g. financial services) demanding high security level, additional PQ KEM= s may be desired for completing the hybrid KEMs for the IKEv2. Currently, I= SO is now standardizing three PQ KEM aglorithms: Kyber, FrodoKEM, and class= ic McElliece. Note that Frodo [Frodo] is unstructured lattice based KEM, whose security is more conservative com= pared to ML-KEM, which is based on structured lattice. Therefore, this draf= t 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 toge= ther, if necessary.<br> ><br> ><br> ><br> > --NEW--<br> ><br> > 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 ha= nd, RFC 9350 allows up to 7 layers of additional KEMs to derive final share= d 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. C= urrently, 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 securi= ty is more conservative compared to ML-KEM, which is based on structured la= ttice. Therefore, this draft is motivated to describe concretely how the fr= ame of hybrid KEMs for the IKEv2 specified in RFC 9370 can be instantiated with FrodoKEM. FrodoKEM should b= e used together with a traditional key exchange mechanism such as ECDH and = in addition, may be used with further KEMs e.g. ML-KEM.<br> ><br> ><br> ><br> ><br> ><br> > Further issues in introduction:<br> ><br> > - Second bullet point: Add a reference for the break of SIKE<br> ><br> > - typos in last paragraph: performace -> performance, triger -><= br> > trigger<br> ><br> ><br> ><br> ><br> ><br> > More typos:<br> ><br> > - section 3, last paragraph:<br> >  = ; stardandization -> standardization<br> >  = ; performace -> performance<br> >  = ; showen -> shown<br> >  = ; roughtly -> roughly<br> >  = ; triger -> trigger<br> ><br> ><br> ><br> ><br> ><br> ><br> ><br> > _______________________________________________<br> > IPsec mailing list -- <a href=3D"mailto:[email protected]">[email protected]= </a><br> > To unsubscribe send an email to <a href=3D"mailto:[email protected]= ">[email protected]</a><br> <br> _______________________________________________<br> CFRG mailing list -- <a href=3D"mailto:[email protected]">[email protected]</a><br> To unsubscribe send an email to <a href=3D"mailto:[email protected]">cfrg= [email protected]</a></span><span lang=3D"EN-US"><o:p></o:p></span></p> </div> </div> </div> </div> </div> </div> </div> </div> </div> </body> </html> --_000_GVXPR07MB96781CB198E9A29FEC817B8E89E02GVXPR07MB9678eurp_-- --===============5623138276912692404== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KQ0ZSRyBtYWls aW5nIGxpc3QgLS0gY2ZyZ0BpcnRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVtYWlsIHRv IGNmcmctbGVhdmVAaXJ0Zi5vcmcK --===============5623138276912692404==--