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<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<https://datatracker.ietf.org/doc/draft-ietf-pquip-pqt-hybrid-terminology/>]. 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<https://www.rfc-editor.org/info/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<https://www.rfc-editor.org/info/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<https://www.rfc-editor.org/info/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<https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/>] desribes how the framework given by RFC 9370 can be run with the post-quantum (PQ) ML-KEM [FIPS203<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>], 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<https://frodokem.org/files/FrodoKEM-standard_proposal-20230314.pdf>] 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<https://datatracker.ietf.org/doc/draft-kampanakis-ml-kem-ikev2/>] describes how the framework given by RFC 9370 can be run with the ML-KEM [FIPS203<https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.pdf>], 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<https://frodokem.org/files/FrodoKEM-standard_proposal-20230314.pdf>] 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 To unsubscribe send an email to ipsec-le...@ietf.org
