Dear all, The below is my review on draft-reddy-ipsecme-ikev2-pqc-auth-04. I also support for adoption but not sure if the issue 0 list mentioned should be considered together.
=========================== REVIEW on draft-reddy-ipsecme-ikev2-pqc-auth-04 Signature Authentication in the Internet Key Exchange Version 2 (IKEv2) using PQC https://www.ietf.org/archive/id/draft-reddy-ipsecme-ikev2-pqc-auth-04.html 0 (Main Comment）: Both this draft and the following draft specifies how to use ML-DSA in the IKEv2, though not via the same approach. Namely, this one uses a SIGNATURE_HASH_ALGORITHMS notify, but [draft-sfluhrer-ipsecme-ikev2-mldsa-00] uses a SUPPORTED_AUTH_METHODS Notify defined in [RFC9593]. So, how to deal with the overlapping here? Consider both in the WG or either of them? draft-sfluhrer-ipsecme-ikev2-mldsa-00 IKEv2 Support of ML-DSA https://datatracker.ietf.org/doc/draft-sfluhrer-ipsecme-ikev2-mldsa/ 1. SLH-DSA has very short public key (32-64 bytes) , but the signature is still a little long (7kB-29kB for the short versions), and signing is much slower than M-DSA (40 times, hundreds times or more, even for fast versions). So, adding some motivations here could be useful to explain why SLH-DSA is also good for the IKEv2. 2. It seems better to give a few tables to compare ML-DSA and SLH-DSA, like key size, digital signature size, and the speed of keyGen, Signing and Verifying. Such info is helpful to users when they need to select ML-DSA or SLH-DSA in their scenario. Noticed that conservative security mentioned in the end of Section 4, but efficiency discussion for SLH-DSA may be also important. 3. In Section 4, "The small version prioritizes smaller signature sizes, making them suitable for resource-constrained environments IoT devices. " Here, any literature or experiments show that SLH-DSA is really good for IoT devises? 4. Beginning of Section 5: It seems better if some text can be given to explain how exactly "a SIGNATURE_HASH_ALGORITHMS notify with an "Identity" (5) hash function' is used to negotiate which particular algorithm of LML-DSA or SLH-DSA will be selected for the IKEv2. 5. Section 5.1: "These methods are equivalent, and so either may be used." This is hard for me to understand: Which is equivalent to which one? And in which sense that they are equivalent? Some minor comments on wording: - Section 1: "Currently, traditional digital signatures are defined for use within IKE_AUTH: RSA signatures, Digital Signature Algorithm (DSA) Digital Signature Standard (DSS) and ECDSA." For this one, it seems better to be more specific via using the exact terms in the "IKEv2 Authentication Method" registry. So, maybe something like this: "Currently, traditional digital signatures are defined for use within IKE_AUTH: RSA Digital Signature (1),DSS Digital Signature (3). ECDSA with three sets of parameters (9, 10, 11), and Digital Signature (14), as listed in the "IKEv2 Authentication Method", maintained by IANA (https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml)." Moreover, it may be worth to say some more words about Digital Signature (14), as this is a general method, which does not specify a particular by itself. - Section 3: - "ML-DSA [FIPS204] is a digital signature algorithm (part of the CRYSTALS suite) based on the hardness lattice problems over module lattices" ==> "ML-DSA [FIPS204] is a digital signature algorithm (part of the CRYSTALS suite) based on the hardness of lattice problems over module lattices" -"... based FS schemes compact and secure", Here "FS scheme" not defined yet really, though the reader may guess it may refer "Fiat-Shamir with Aborts" [Lyu09]. Also, not sure if it is good to call this "FC scheme" as it is an approach following FC work but improved by Lyubashevsky. -Section 7: "it trusts a certificate authority certificate signed by an ML-DSA or SLH-DSA key." Here, should "a certificate authority certificate" be replaced by "a certification authority certificate"? -Section 7: "[I-D.ietf-ipsecme-ikev2-auth-announce]" is now RFC 9593. =========================== Guilin -----Original Message----- From: Michael Richardson <mcr+i...@sandelman.ca> Sent: Saturday, 1 March 2025 3:37 am To: ipsec@ietf.org Subject: [IPsec] Re: WG Adoption call of draft-reddy-ipsecme-ikev2-pqc-auth Panwei \(William\) <william.panwei=40huawei....@dmarc.ietf.org> wrote: > The PQC algorithms, such as ML-DSA and SLH-DSA, don't perfectly fit > with the original IKEv2 authentication architecture. For example, this > is discussed in Section 5.2 of the document. So, we need to consider > how to process with this situation, whether we need to expand the > architecture. This part is 1) of Paul's email. And I agree that this > general considerations should be a separate draft. Although currently > ML-DSA and SLH-DSA are the only standardized signature algorithms, > there will be more algorithms being standardized in the future. We need > to have the consideration for the general mechanism now, rather than > designing one by one. > As a practical manner, I suggest adopting the current draft as is, and > then discussing (splitting) the general mechanism part later by > considering other possible PQC signature algorithms. I agree: adopt it as is, and fix it. I'm not quite convinced we can't do the general mechanism in this document, and then apply it to ML-DSA and SLH-DSA. I think that readers/reviewers would precer that. But, I don't feel strongly about this. -- Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
