Thanks John for the detailed review, fixed the comments in https://github.com/tireddy2/ikev2-pqc-auth/pull/29
Cheers, -Tiru On Thu, 9 Oct 2025 at 22:25, John Mattsson <[email protected]> wrote: > I think this is ready, I only have editorial comments. > > Cheers, > John > > ----- > > - "Currently, traditional digital signatures are defined for use within > > IKE_AUTH: RSA signatures, Digital Signature Algorithm (DSA) Digital > > Signature Standard (DSS) and ECDSA." > > > > EdDSA is also defined. Could give a subset as an example. DSA could e.g. > be excluded. > > https://datatracker.ietf.org/doc/rfc8420/ > > > > My understanding is that the term "Digital Signature Standard (DSS)" > covers all signatures in FIPS 185 > > > > - "Cryptographically Relevant Quantum Computer (CRQC) would render > state-of-the-art traditional asymmetric algorithms obsolete and insecure" > > > > Also the not so state-of-the-art. I suggest removing "state-of-the-art" > > > > - "elliptic curve discrete logarithms, elliptic curve discrete logarithms" > > > > - OLD: "AlgorithmIdentifier ASN.1 objects" > > NEW: "DER encoded AlgorithmIdentifier ASN.1 objects" > > > > - "In the context of signature-based authentication in IKEv2, the data > > used for generating a digital signature is unique for each session, > > as it includes session-specific information such as nonces, > > cryptographic parameters, and identifiers." > > > > I think this sentence would be better if "cryptographic parameters, and > identifiers." are removed. The data is unique as it includes the nonces. > Cryptographic parameters, and identifiers are not session-specific. > > > > - I think the document should inform the reader that external-μ is part of > "pure" and can be used. The term "pre-hash" term can be confusing as is > sometimes used differently. > > > > - OLD "listing the PQC signature scheme(s) it supports." > > NEW "listing the signature scheme(s) it supports." > > > > My understanding is that RFC 9593 allows non-PQC > > > > - "is increasingly important for long-term security and interoperability" > > > > I am not sure about that crypto agility "is increasingly important", I > would suggest something like "the importance of crypto-agility is gaining > increased attention.” I think it has always been very important. > > > > - "easier to implement" > > > > Easier than what? > > > > - "with 3 parameter sets" > > > > - "In contrast to stateful signature algorithms" > > > > Most readers probably don't know these exist > > > > - The second approach involves using the Externalμ-ML-DSA API defined in > [I-D.ietf-lamps-dilithium-certificates] > > > > I think you should refer to FIPS 204 for External-μ. You may also refer to > I-D.ietf-lamps-dilithium-certificates, but an IKEv2 implementation might > not use a different API than I-D.ietf-lamps-dilithium-certificates. > > > > "Externalμ-ML-DSA.Prehash" > > "such as whether the pre-hashing step" > > > > I don't think the word pre-hash should be used for External-μ. In FIPS > 204, "pre-hash" means HashML-DSA. > > > > - Are identified via AlgorithmIdentifier ASN.1 objects, as specified in > [I-D.ietf-lamps-x509-slhdsa] > > > > I think this should refer to NIST CSOR. > > > > - In general, I think the draft has to few references to NIST. A lot of > references that I should be to FIPS 204, FIPS 205, NIST CSOR, etc, are > instead to draft replicating NIST. > > > > - some schemes align with the security of AES-128, AES-192, > > and AES-256, while others correspond to the security levels of > > SHA-256 or SHA3-256. > > > > I think this should refer to the NIST security categories. The security of > SHA-256 can mean different things (256 preimage, 128 collision, 0 length > extention, etc.) > > > > - "SLH-DSA keys are limited to 2^64 signatures" > > > > I think you should also state that "ML-DSA does not have a built-in > signature limit, allowing for an arbitrary number of signatures to be made > with the same key" > > --- > > > > On 2025-10-08, 09:44, "Tero Kivinen via Datatracker" <[email protected]> > wrote: > > > > Subject: WG Last Call: draft-ietf-ipsecme-ikev2-pqc-auth-04 (Ends > 2025-10-22) > > > > This message starts a 2-week WG Last Call for this document. > > > > Abstract: > > Signature-based authentication methods are utilized in IKEv2 > > [RFC7296]. The current version of the Internet Key Exchange Version > > 2 (IKEv2) protocol supports traditional digital signatures. > > > > This document specifies a generic mechanism for integrating post- > > quantum cryptographic (PQC) digital signature algorithms into the > > IKEv2 protocol. The approach allows for seamless inclusion of any > > PQC signature scheme within the existing authentication framework of > > IKEv2. Additionally, it outlines how Module-Lattice-Based Digital > > Signatures (ML-DSA) and Stateless Hash-Based Digital Signatures (SLH- > > DSA), can be employed as authentication methods within the IKEv2 > > protocol, as they have been standardized by NIST. > > > > File can be retrieved from: > > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc-auth/ > > > > Please review and indicate your support or objection to proceed with the > > publication of this document by replying to this email keeping > [email protected] > > in copy. Objections should be motivated and suggestions to resolve them are > > highly appreciated. > > > > Authors, and WG participants in general, are reminded again of the > > Intellectual Property Rights (IPR) disclosure obligations described in BCP > 79 > > [1]. Appropriate IPR disclosures required for full conformance with the > > provisions of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of > > any. Sanctions available for application to violators of IETF IPR Policy > can > > be found at [3]. > > > > Thank you. > > > > [1] https://datatracker.ietf.org/doc/bcp78/ > > [2] https://datatracker.ietf.org/doc/bcp79/ > > [3] https://datatracker.ietf.org/doc/rfc6701/ > > > > > > > > >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
