The revised draft draft-reddy-ipsecme-ikev2-pqc-auth-04 incorporates text from draft-sfluhrer-ipsecme-ikev2-mldsa. Please see Scott's message: https://mailarchive.ietf.org/arch/msg/ipsec/w8YvU191Fm4SxGvofW20chGFKtc/, draft-sfluhrer-ipsecme-ikev2-mldsa will no longer be pursued.
-Tiru On Fri, 7 Mar 2025 at 15:14, Wang Guilin <Wang.Guilin= 40huawei....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
