Ok, finally found time to review this document. Here is my comments to
it.
The main body of the document seems to be fine (except references),
but from section 6 forward it seems to include information that is not
needed in this draft.
The section "6. Implementation Alternatives for ML-DSA" talks about
different approaches to impleenting and refers to "Externalμ-ML-DSA
API defined in [FIPS204]." which I do not find from FIPS204.
Then in the end it says
Both approaches are considered "pure" mode and produce the same ML-
DSA signature and are fully interoperable. The choice between them
depends on implementation preferences, such as whether the External μ
pre-hashing step is handled internally by the cryptographic module or
performed explicitly by the IKEv2 implementation.
if it does not matter which alternative is used, then why even mention
it here. I would propose just removing whole section 6.
--
In section "7. Use of ML-DSA and SLH-DSA" the first paragraph again
goes to explaining different alternatives:
Both ML-DSA and SLH-DSA offer deterministic and hedged signing modes.
By default, ML-DSA uses a hedged approach, where the random value rnd
is a 256-bit string generated by an Random Bit Generator (RBG). The
signature generation function utilizes this randomness along with the
private key and the preprocessed message. In the deterministic
variant, rnd is instead set to a constant 256-bit zero string.
Similarly, SLH-DSA can operate in either deterministic or hedged
mode. The mode is determined by the value of opt_rand, when opt_rand
is set to a fixed value (e.g., the public seed from the public key),
SLH-DSA generates deterministic signatures, ensuring that signing the
same message twice produces the same signature. In hedged mode,
opt_rand is a fresh random value, introducing additional entropy to
enhance security and mitigate potential side-channel risks.
and then says either one of them can be used.
What is the purpose of the first paragraph? I would just remove that
first paragraph.
--
In section "8. Security Considerations" there is text:
ML-DSA-44, ML-DSA-65, and ML-DSA-87 are designed to offer security
comparable with the SHA-256/SHA3-256, AES-192, and AES-256
respectively. Similarly, SLH-DSA-128{S,F}-{SHA2,SHAKE}, SLH-DSA-
Why is the ML-DSA-44 comparible with SHA-256/SHA3-256, but not with
any cipher like AES-128?
Was it supposed to say that ML-DSA-44 offers security comparable with
the AES-128?
--
Normative references:
I think the "IKE and IKEv2 Authentication Using the Elliptic Curve
Digital Signature Algorithm (ECDSA)", RFC 4754 is not normative
reference, it is just referenced as one of the other types of digital
signature methods for IKEv2.
Move it to informational reference.
--
Normative references:
Same for "Internet Key Exchange Protocol Version 2 (IKEv2) Message
Fragmentation", RFC 7383 and "Announcing Supported Authentication
Methods in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
9593 which both are used when pointed out that these optional
extensions to IKEv2 might be useful when implementing this.
Either one of them is not really normative, move those to
informational references.
--
Normative references:
"Using the Edwards-Curve Digital Signature Algorithm (EdDSA) in the
Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 8420 would have
been informational referece otherwise, but as we do refer the
"Identity" hash function from there, I think it needs to say
normative.
--
Informative references:
On the other hand I would say that "NIST, Secure Hash Standard (SHS),
FIPS PUB 180-4, "NIST, SHA-3 Standard: Permutation-Based Hash and
Extendable-Output Functions, FIPS PUB 202, "FIPS 204:
Module-Lattice-Based Digital Signature Standard", FIPS PUB 204, and
"FIPS 205: Stateless Hash-Based Digital Signature Standard", FIPS PUB
205 are all normative, you do need to use those to be able to
implement this draft.
Move them to normative references.
--
Why should we keep Appendix A at all at this point?
It was most likely useful while working on this document but leaving
this kind background information is actually bad idea. I have seen a
vendor who decided to implement things from the "options not selected"
appendix just "because that option was mentioned in the RFC". They did
not care that it was one the options that was NOT selected...
I would either propose removing this now, or adding a note that this
appendix will be removed before publishing this as RFC.
And if removeing Appendix A, then remove this paragraph from 3.2.1:
For additional background on design alternatives that were considered
and the rationale for adopting the [RFC8420] approach as the cleanest
and most secure method, see Appendix A.
(if not, then add proper document name for RFC8420)
--
In the Appendix B the binary ASN.1 objects contains SEQUENCE which has
the OID number inside. This is because of the way algorithm
identifiers are done, i.e., there could also be parameters etc there,
but as parameters are always omitted, there is just the outer
SEQUENCE. Perhaps adding text in the beginning of Appendix B to
explain this would be good thing. It took me some time to remember why
the SEQUENCE is there...
--
And then there is my normal thing to complain when you have [RFCxxx],
you should always have some kind of useful name for the RFC number, do
not just assume everybody remembers all 10000 RFCs.
List of those changes below:
----------------------------------------------------------------------
Section 1:
The traditional cryptographic
primitives that need to be replaced by PQC algorithms are discussed
in [I-D.ietf-pquip-pqc-engineers].
change to
The traditional cryptographic
primitives that need to be replaced by PQC algorithms are discussed
in PQC for Engineers [I-D.ietf-pquip-pqc-engineers].
--
In section 2:
This document uses terms defined in
[I-D.ietf-pquip-pqt-hybrid-terminology].
change to
This document uses terms defined in Terminology for PQ/T Hybrid
Schemes [I-D.ietf-pquip-pqt-hybrid-terminology].
--
Section 3.1:
* IKEv2 can use arbitrary signature algorithms as described in
[RFC7427], where the "Digital Signature" authentication method
supersedes previously defined signature authentication methods.
Any PQC digital signature algorithm can be incorporated using the
"Signature Algorithm" field in authentication payloads, as defined
in [RFC7427].
change to
* IKEv2 can use arbitrary signature algorithms as described in
Signature Authentication in IKEv2 [RFC7427], where the "Digital
Signature" authentication method supersedes previously defined
signature authentication methods. Any PQC digital signature
algorithm can be incorporated using the "Signature Algorithm"
field in authentication payloads, as defined in [RFC7427].
--
Section 3.2:
The terms deterministic and hedged used in this document are
in accordance with [FIPS204] and [FIPS205], which define the ML-DSA
and SLH-DSA algorithms.
change to
The terms deterministic and hedged used in this document are
in accordance with ML-DSA [FIPS204] and SLH-DSA [FIPS205] algorithms.
--
Section 3.2:
The data used for authentication in IKEv2, as described in
Section 2.15 of [RFC7296], consists of elements such as nonces, SPIs,
change to
The data used for authentication in IKEv2, as described in
Section 2.15 of IKEv2 [RFC7296], consists of elements such as
nonces, SPIs,
--
Section 3.2.1:
As specified in [RFC7427], both the initiator and responder MUST send
the SIGNATURE_HASH_ALGORITHMS notify payload in the IKE_SA_INIT
change to
As specified in Signature Authentication in IKEv2 [RFC7427], both
the initiator and responder MUST send the SIGNATURE_HASH_ALGORITHMS
notify payload in the IKE_SA_INIT
and
'Identity' hash function is applicable. The 'Identity' hash function
(value 5) is defined in Section 2 of [RFC8420] and indicates that the
change to
'Identity' hash function is applicable. The 'Identity' hash
function (value 5) is defined in Section 2 of Using EdDSA in IKEv2
[RFC8420] and indicates that the
and
IKEv2 peers supporting the PQC authentication mechanism defined in
this specification SHOULD implement IKEv2 message fragmentation as
specified in [RFC7383], unless IKEv2 runs over a reliable transport
(e.g., [RFC9329]) or the underlying network is known to support
sufficiently large MTUs without fragmentation issues, since PQC
public keys and signatures can be significantly larger than those
used in traditional algorithms. For example, ML-DSA-44 requires a
public key of 1,312 bytes and a signature of 2,420 bytes, while even
the smallest SLH-DSA signature is around 7,856 bytes. As guidance,
IKEv2 peers should assume a minimum PMTU of 1280 bytes for IPv6 (per
[RFC8200]) and, where legacy IPv4 networks are a consideration, an
effective MTU of 576 bytes for IPv4 (per [RFC1122]).
change to
IKEv2 peers supporting the PQC authentication mechanism defined in
this specification SHOULD implement IKEv2 message fragmentation
[RFC7383], unless IKEv2 runs over a reliable transport (e.g., TCP
Encapsulation of IKEv2 and IPsec [RFC9329]) or the underlying
network is known to support sufficiently large MTUs without
fragmentation issues, since PQC public keys and signatures can be
significantly larger than those used in traditional algorithms. For
example, ML-DSA-44 requires a public key of 1,312 bytes and a
signature of 2,420 bytes, while even the smallest SLH-DSA signature
is around 7,856 bytes. As guidance, IKEv2 peers should assume a
minimum PMTU of 1280 bytes for IPv6 (per IPv6 [RFC8200]) and, where
legacy IPv4 networks are a consideration, an effective MTU of 576
bytes for IPv4 (per Requirements for Internet Hosts [RFC1122]).
--
Section 3.3:
Certificate Request payload (defined in Section 3.7 of [RFC7296])
change to
Certificate Request payload (defined in Section 3.7 of IKEv2
[RFC7296])
and
* Authentication Method Announcement: Another method is to utilize
[RFC9593],
change to
* Authentication Method Announcement: Using Announcing Supported
Authentication Method in IKEv2 [RFC9593],
(why is there newline after the rfc number?)
--
Section 4:
ML-DSA is instantiated with three parameter sets for the security
categories 2, 3, and 5 (see Table 2 in Section 10 of
[I-D.ietf-pquip-pqc-engineers]). Security properties of ML-DSA are
discussed in Section 9 of [I-D.ietf-lamps-dilithium-certificates].
change to
ML-DSA is instantiated with three parameter sets for the security
categories 2, 3, and 5 (see Table 2 in Section 10 of PQC for
Engineers [I-D.ietf-pquip-pqc-engineers]). Security properties of
ML-DSA are discussed in Section 9 of PKIX Algorithm Identifiers for
the ML-DSA [I-D.ietf-lamps-dilithium-certificates].
--
Section 5:
(see Table 2 in Section 10 of [I-D.ietf-pquip-pqc-engineers]).
change to
(see Table 2 in Section 10 of PQC for Engineers
[I-D.ietf-pquip-pqc-engineers]).
--
Section 6:
(see Appendix D of [I-D.ietf-lamps-dilithium-certificates])
change to
(see Appendix D of PKIX Algorithm Identifiers for the ML-DSA
[I-D.ietf-lamps-dilithium-certificates])
--
Section 7:
The three security levels of ML-DSA are identified via
AlgorithmIdentifier ASN.1 objects, as specified in NIST [CSOR] and
referenced in [I-D.ietf-lamps-dilithium-certificates]. [FIPS204]
defines both a pure and a pre-hash variant of ML-DSA, but
[I-D.ietf-lamps-dilithium-certificates] specifies only the pure
variant.
The different combinations of SLH-DSA are identified via
AlgorithmIdentifier ASN.1 objects, as specified in NIST [CSOR] and
referenced in [I-D.ietf-lamps-x509-slhdsa]. [FIPS205] defines two
signature modes: pure mode and pre-hash mode.
[I-D.ietf-lamps-x509-slhdsa] specifies the use of both Pure SLH-DSA
and HashSLH-DSA in Public Key Infrastructure X.509 (PKIX)
certificates and Certificate Revocation Lists (CRLs).
change to
The three security levels of ML-DSA are identified via
AlgorithmIdentifier ASN.1 objects, as specified in NIST Computer
Security Objects Register [CSOR] and referenced in PKIX Algorithm
Identifiers for the ML-DSA [I-D.ietf-lamps-dilithium-certificates].
ML-DSA [FIPS204] defines both a pure and a pre-hash variant of
ML-DSA, but PKIX Algorithm Identifiers for the ML-DSA
[I-D.ietf-lamps-dilithium-certificates] specifies only the pure
variant.
The different combinations of SLH-DSA are identified via
AlgorithmIdentifier ASN.1 objects, as specified in NIST Computer
Security Objects Register [CSOR] and referenced in PKIX Algorithm
Identifiers for the SLH-DSA [I-D.ietf-lamps-x509-slhdsa]. SLH-DSA
[FIPS205] defines two signature modes: pure mode and pre-hash mode.
PKIX Algorithm Identifiers for the SLH-DSA
[I-D.ietf-lamps-x509-slhdsa] specifies the use of both Pure SLH-DSA
and HashSLH-DSA in Public Key Infrastructure X.509 (PKIX)
certificates and Certificate Revocation Lists (CRLs).
--
Section 8:
PQC signature algorithms are generally modeled to achieve strong
unforgeability under adaptive chosen-message attacks (SUF-CMA; see
Section 10.1.1 of [I-D.ietf-pquip-pqc-engineers]). For example, ML-
DSA provides SUF-CMA security. However, some algorithms, such as
SLH-DSA, achieve existential unforgeability under chosen-message
attacks (EUF-CMA; see Section 10.1.1 of
[I-D.ietf-pquip-pqc-engineers]). This distinction does not impact
IKEv2,
change to
PQC signature algorithms are generally modeled to achieve strong
unforgeability under adaptive chosen-message attacks (SUF-CMA; see
Section 10.1.1 of PQC for Engineers
[I-D.ietf-pquip-pqc-engineers]). For example, ML- DSA provides
SUF-CMA security. However, some algorithms, such as SLH-DSA,
achieve existential unforgeability under chosen-message attacks
(EUF-CMA; see Section 10.1.1 of PQC for Engineers
[I-D.ietf-pquip-pqc-engineers]). This distinction does not impact
IKEv2,
--
Section 8:
For example, some schemes align with the NIST post-quantum security
categories (Categories 1 through 5) as discussed in [FIPS204] and
[FIPS205].
change to
For example, some schemes align with the NIST post-quantum security
categories (Categories 1 through 5) as discussed in ML-DSA
[FIPS204] and SLH-DSA [FIPS205].
--
Section 8:
The Security Considerations section of
[I-D.ietf-lamps-dilithium-certificates] and
[I-D.ietf-lamps-x509-slhdsa] apply to this specification as well.
change to
The Security Considerations section of PKIX Algorithm Identifiers
for the ML-DSA [I-D.ietf-lamps-dilithium-certificates] and PKIX
Algorithm Identifiers for the SLH-DSA [I-D.ietf-lamps-x509-slhdsa]
apply to this specification as well.
--
[email protected]
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
