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]<mailto:[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]
