Mahesh Jethanandani has entered the following ballot position for draft-ietf-ipsecme-ikev2-pqc-auth-11: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-pqc-auth/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks first of all to the authors for working on this document. Much like Ketan, I am not an expert in security or IKEv2, but something caught my attention that I think would be worth discussing. ection 3.2.1, Handling PQC Signatures in IKEv2, Identity-hash gating: 253 > Version 2 (IKEv2)" [RFC8420] and indicates that the input message is 254 > used as-is, without any hash function applied. Therefore, 255 > implementations supporting such PQC signature algorithms MUST include 256 > the 'Identity' hash (5) in the SIGNATURE_HASH_ALGORITHMS 257 > notification. Furthermore, PQC signature algorithms requiring the 258 > 'Identity' hash MUST NOT be used with a peer that has not indicated 259 > support for the Identity hash in its notify payload. The SIGNATURE_HASH_ALGORITHMS notification travels in the IKE_SA_INIT exchange, which RFC 7296 sends entirely in the clear if my understanding is correct. That makes the MUST NOT above an unauthenticated gate. An active on-path attacker who strips or zeroes the Identity-hash bit from a peer's SIGNATURE_HASH_ALGORITHMS notification during IKE_SA_INIT causes the other side to conclude, per this exact rule, that it cannot use any PQC signature algorithm with that peer, since every PQC scheme this document defines requires the Identity hash, and to fall back silently to a traditional algorithm such as RSA or ECDSA. That's precisely the algorithm class a CRQC-capable adversary is assumed to break, and such an adversary doesn't need the quantum computer to pull this off: removing a two-octet hash-algorithm ID from an unauthenticated notify payload is well within range of an ordinary on-path attacker today. What is different from RFC 9593 here is the "MUST NOT be used with a peer that has not indicated support" language makes Identity-hash support a hard precondition for using any PQC algorithm at all. Section 8 doesn't mention this risk at all. I'd like the authors to add text to Security Considerations acknowledging it and giving implementers guidance on avoiding a silent downgrade -- for example, a local policy option to hard-fail the negotiation rather than fall back when PQC authentication is required for that peer. This dovetails with Ketan's point about the document lacking guidance for the "PQC-mandatory" deployment case. I don't think this needs a protocol fix, but it needs acknowledgment and guidance in the text, some of which can be made in an Operational Considerations section (see comment below). ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 8, Security Considerations, SUF-CMA/EUF-CMA paragraph: 453 > PQC signature algorithms are generally modeled to achieve strong 454 > unforgeability under adaptive chosen-message attacks (SUF-CMA; see 455 > Section 10.1.1 of PQC for Engineers [RFC9958]). For example, ML-DSA 456 > provides SUF-CMA security. However, some algorithms, such as SLH- 457 > DSA, achieve existential unforgeability under chosen-message attacks 458 > (EUF-CMA; see Section 10.1.1 of PQC for Engineers [RFC9958]). This 459 > distinction does not impact IKEv2, as the signed data in each session 460 > is unique due to the inclusion of nonces. Consequently, the oracle- 461 > based forgery attack scenarios in the EUF-CMA model do not arise in 462 > IKEv2. Mike Bishop noted that this text "suggests a distinction between the two, but the citation suggests they should be equivalent." He's right, and having gone and read RFC 9958 Section 10.1.1 myself, the citation doesn't just "suggest" equivalence -- it states it outright: > SUF-CMA (strong unforgeability under chosen message attack) builds upon > EUF-CMA by requiring that an adversary cannot produce a different valid > signature for a message that has already been signed by the signing > oracle. [...] ML-DSA, FN-DSA, and SLH-DSA also achieve SUF-CMA security. All three algorithms, not just ML-DSA. As written, this paragraph doesn't merely cite the wrong nuance -- it draws a distinction between ML-DSA and SLH-DSA that its own cited source explicitly says doesn't exist. I'd suggest either dropping the SUF-CMA/EUF-CMA contrast and just noting both algorithms meet SUF-CMA per RFC 9958, or citing a source that actually supports treating SLH-DSA as EUF-CMA-only. -- Missing Operational Considerations section: draft-ietf-opsawg-rfc5706bis recommends an Operational Considerations section ahead of Security Considerations for documents defining protocol extensions. This document adds a new negotiable authentication mechanism with real deployment questions attached -- which PQC algorithms a given site trusts, whether PQC authentication is mandatory or opportunistic (see Ketan's comment and my DISCUSS above) -- none of which is addressed outside the protocol mechanics in Sections 3-6. The authors might consider a short section on this, even if it just states that algorithm trust and PQC- mandatory policy are local matters outside the document's scope. --- Section 3.2, side-channel reference requested by OPSDIR: 200 > In the deterministic mode, the signature is derived entirely from the 201 > message and the signer's private key, without introducing fresh 202 > randomness at signing time. While this eliminates reliance on an 203 > external random number generator, it increases susceptibility to 204 > side-channel attacks, particularly fault injection attacks. I thank Tony Li (OPSDIR) for asking that this paragraph add "a reference for side-channel attacks and how they might apply to deterministic mode." The authors indicated on the list they'd address it via a PR, but I don't see a citation added in -11 -- this sentence is unchanged and still unreferenced. Worth confirming this lands before publication. ---------------------------------------------------------------------- NIT ---------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools (via https://github.com/larseggert/ietf-reviewtool), so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Informative References, [Lyu09] entry, mismatched quote marks: 568 > [Lyu09] "V. Lyubashevsky, “Fiat-Shamir With Aborts: Applications 569 > to Lattice and Factoring-Based Signatures“, ASIACRYPT s/Signatures“, ASIACRYPT/Signatures”, AISACRYPT"/ Appendix A, inconsistent rendering of "External μ": 634 > The second approach involves using the Externalμ-ML-DSA API allowed s/Externalμ-ML-DSA/External μ-ML-DSA/ (also at line 641; compare "External μ" with a space at lines 636, 640, and 650-651) Appendix B, missing blank line before "Parameters are absent.": 694 > id-ml-dsa-87(19) } 695 > Parameters are absent. Every other entry in Appendix B has a blank line between the closing brace of the OBJECT IDENTIFIER and "Parameters are absent."; B.3 is missing it, and the same slip recurs at B.7 (lines 741-742), B.11 (lines 788-789), and B.15 (lines 835-836). Section 8, article usage: 488 > large that even a IKEv2 server establishing IKEv2 sessions at an s/even a IKEv2 server/even an IKEv2 server/ _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
