Hi Mahesh, thank you for your comments. Please, see inline.
> 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. This 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. This is not correct. The content of the SIGNATURE_HASH_ALGORITHMS notification is authenticated (as part of the entire IKE_SA_INIT message) during the IKE_AUTH exchange. If active attacker modifies the SIGNATURE_HASH_ALGORITHMS, it should also be able to forge the signature for the peer, whose IKE_SA_INIT message is changed (and if peers support draft-ietf-ipsecme-ikev2-downgrade-prevention, the attacker would need to forge both signatures, even only one IKE_SA_INIT message is modified). That said, if the attacker has a CRQC that is able to break traditional signatures in real time and peers support both PQ and traditional signatures, then the attacker can mount a downgrade attack by removing indications for PQC support from the SIGNATURE_HASH_ALGORITHMS and SUPPORTED_AUTH_METHODS notifications, forcing peers to use traditional signatures, and then forging these signatures by means of CRQC making the IKE_AUTH complete. This is not a particular issue of IKEv2, any protocol that allows selection of authentication methods between traditional signatures and PQ signatures during protocol run is susceptible to such an attack (e.g., TLS 1.3). This can only be prevented by administratively prohibiting traditional signatures. > 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. This is true, but it was intended. > 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. Done. > 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). We added the Operational Considerations section. > ---------------------------------------------------------------------- > 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. This is fixed. > 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. This section is added. > 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. Added. Regards, Valery (for authors). > ---------------------------------------------------------------------- > 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]
