Hi Valery,
Thanks for addressing my DISCUSS and COMMENTs. I will clear my ballot with one
comment. The comment relates to Paul Wouters’ point on the OPSDIR thread that
an implementation supporting only one of ML-DSA/SLH-DSA can't cleanly claim
"RFC XXXX supported," and Wang Guilin's suggested fix ("supports ML-DSA [RFC
XXXX]"),
don't appear to have made it into Section 6 of -12. It is a non-blocking
comment, and I will let you decide how you want to handle it.
Cheers.
> On Aug 20, 2026, at 2:06 AM, Valery Smyslov <[email protected]> wrote:
>
> 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/
Mahesh Jethanandani
[email protected]
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
