Thank you for the thorough review Rebecca. I will take care of those. The only objection I have is on the comment about ML-KEM-512 because the -03 version is asking for an OID for ML-KEM-512. Previously it did not, but I added it in the latest one. And I also added a note about fragmentation > [I-D.ietf-pquip-pqt-hybrid-terminology-02<https://datatracker.ietf.org/doc/html/draft-ietf-pquip-pqt-hybrid-terminology-02>] > scenario, ML-KEM-512 and ML-KEM-768 Key Exchange Method identifiers TBD35 > and TBD36 respectively MAY be used in IKE_SA_INIT as a quantum-resistant-only > key exchange. The encapsulation key and ciphertext sizes for these ML-KEM > parameters may not push the UDP packet to size larger than typical network > MTUs of 1500 bytes. [EDNOTE: Confirmed with sample captures where the total > UDP size does not exceed 1400. ] ML-KEM-1024 Key Exchange Method identifier > TBD37 SHOULD NOT be used in IKE_SA_INIT messages which could exceed typical > network MTUs and cannot be IKEv2 fragmented.
I am not sure, but did the IPSECME WG decide if this draft will get OIDs assigned from Expert Review or if we will go the ratified RFC route? I think it was not discussed in IETF-120? Maybe someone on the list of the chairs remember? From: Rebecca Guthrie <rmguthr=40uwe.nsa....@dmarc.ietf.org> Sent: Thursday, August 1, 2024 8:20 PM To: ipsec@ietf.org Subject: [EXTERNAL] [IPsec] Comments on draft-kampanakis-ml-kem-ikev2-03 CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Hi all, I reviewed draft-kampanakis-ml-kem-ikev2-03 and have provided some comments and suggestions below: "A Cryptanalytically-relevant Quantum Computer (CRQC), if it became a reality, could threaten public key encryption algorithms used today for key exchange." public key encryption algorithms -> public key establishment algorithms used today for key exchange -> used today ---------------------------------------------------------------------------------------------------------------------------------- "Someone storing encrypted communications which use (Elliptic Curve) Diffie-Hellman ((EC)DH) to negotiate keys could decrypt these communications in the future after a CRQC was available." which use -> that used negotiate -> establish was available -> became available to them ---------------------------------------------------------------------------------------------------------------------------------- I suggest a reordering of the information in paragraphs 2 and 3- I think it could be clearer that RFC 9242 and RFC 9370, though standardized prior to ML-KEM, were written to help facilitate the use of PQ KEMs like ML-KEM in IKEv2. Perhaps something like this (also included some other edits to the text): Before the existence of standardized quantum-resistant key establishment algorithms, [RFC8784] provided an interim solution for this concern by introducing Post-quantum Preshared Keys, a high entropy pre-shared key to be stirred into the derived Child SA encryption keys in order to provide quantum resistance. Since then, NIST has been working on a public project [NIST-PQ] for standardizing quantum-resistant algorithms which include Key Encapsulation Mechanisms (KEMs) and digital signatures. At the end of Round 3, they picked Kyber as the first KEM for standardization [I-D.draft-cfrg-schwabe-kyber-04]. NIST published a draft standard [FIPS203-ipd] that specified Kyber as Module-Lattice-based Key-Encapsulation Mechanism (ML-KEM). ML-KEM was standardized in 2024 [FIPS203]. [ EDNOTE: Reference normatively the ratified version [I-D.draft-cfrg-schwabe-kyber-04] if it is ever ratified. Otherwise keep a normative reference of [FIPS203]. And remove the reference to [FIPS203-ipd].] As post-quantum KEM public keys and ciphertexts may make UDP packet sizes larger than common network Maximum Transmission Units (MTU), [RFC9242] defines new IKE_INTERMEDIATE and IKE_FOLLOWUP_KE messages that, along with [RFC9370] can allow for peers to do post-quantum key establishment. In particular, these messages can be fragmented at the IKEv2 layer before exceeding MTU and causing IP fragmentation [RFC7383]. Because [RFC9242] messages can only be used after IKE_SA_INIT, if a PQ KEM does not fit inside IKE_SA_INIT without causing IP fragmentation, then it must be used after IKE_SA_INIT as an additional key establishment algorithm. [RFC9370] defines how to perform up to seven additional key exchanges by using IKE_INTERMEDIATE or IKE_FOLLOWUP_KE messages and deriving new SKEYSEED and KEYMAT key materials. This allows for new post-quantum key exchanges to be used in the derived IKE and Child SA keys and provide quantum resistance. ---------------------------------------------------------------------------------------------------------------------------------- Since this draft discusses all three parameters of ML-KEM, I wonder if it would be cleaner for this draft to request an OID for ML-KEM-512 as well, and additionally to profile how to use ML-KEM-512 and ML-KEM-768 in IKE_SA_INIT, rather than pushing these things to a separate future document. If such a document is written, it would create a dependency on this one for the ML-KEM-768 OID. I don't have an opinion one way or another on whether or not ML-KEM-512 should be assigned an OID here, other than thinking it makes sense for the sake of completeness (if no one is planning on using ML-KEM-512, then it makes more sense to not do so here). I do think though it would be good to profile how to use ML-KEM-768 in IKE_SA_INIT, even if ML-KEM-512 is ultimately not included. If the decision is made to not request an OID for ML-KEM-512, it would probably be better to only mention it once in Section 1.2 with a comment about why it was not profiled, and then not be mentioned throughout the rest of the document. ---------------------------------------------------------------------------------------------------------------------------------- In paragraph 4, regarding this sentence: "This approach of combining a quantum-resistant with a classical algorithm, is commonly called Post-Quantum Traditional (PQ/T) Hybrid [I-D.ietf-pquip-pqt-hybrid-terminology-02] key exchange and combines the security of a well-established algorithm with relatively new quantum-resistant algorithms which could theoretically have unknown issues." I agree that it is useful to reference [I-D.ietf-pquip-pqt-hybrid-terminology-02], but the sentence reads as if one need have security concerns with ML-KEM or its implementation as a prerequisite in order to use this draft. It might be more appropriate to cite this as one motivation for this draft, and to also acknowledge that other implementors may use a hybrid solution here strictly because their desired ML-KEM parameter does not fit in IKE_SA_INIT. And a nit: "classical" -> "traditional" (in order to align with the draft being referenced) Rebecca Rebecca Guthrie she/her Center for Cybersecurity Standards (CCSS) Cybersecurity Collaboration Center (CCC) National Security Agency (NSA)
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
