Thanks Mahesh for the detailed review. I have raised https://github.com/tireddy2/ikev2-pqc-auth/pull/45 to address the DISCUSS and comments.
-Tiru On Wed, 19 Aug 2026 at 01:20, Mahesh Jethanandani via Datatracker < [email protected]> wrote: > 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]
