Hi Mahesh, thank you for your comments. Please see inline.
> -----Original Message----- > From: Mahesh Jethanandani via Datatracker <[email protected]> > Sent: Friday, June 26, 2026 9:23 PM > To: The IESG <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; > [email protected] > Subject: Mahesh Jethanandani's No Objection on > draft-ietf-ipsecme-ikev2-downgrade-prevention-07: (with > COMMENT) > > Mahesh Jethanandani has entered the following ballot position for > draft-ietf-ipsecme-ikev2-downgrade-prevention-07: No Objection > > 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-downgrade-prevention/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I agree with both of Boucadair's DISCUSS points. RFC 9242 is a normative > dependency because Section 7.1 contains a MUST that depends on the IntAuth > term defined in RFC 9242, and the entire IKE_INTERMEDIATE interaction is > meaningless without reading that RFC. RFC 5723 is a normative dependency > because Section 7.2 contains two MUSTs ("MUST be stored in the ticket" and > "MUST act the same way when doing resumption") that depend on the ticket > mechanism defined in RFC 5723. Both should be listed as normative references. We have a different perspective. We think that both extensions (RFC 9242 and RFC 5723) are optional for implementing and the downgrade prevention can be implemented without implementing them, thus we think that making them normative is not needed for a general case. Anyway, we see your point too, and for the sake of moving draft forward we changed the text in Section 7, so that normative language is not used there anymore. Hopefully, this will resolve your concerns. > Section 9, first paragraph — incomplete statement: > > 433 > The IKEv2 extension defined in this document protects against > 434 > downgrade attacks on IKEv2 described in Section 4. It only provides > 435 > this protection when both peers implement the extension. > > In my view, the second sentence is an incomplete statement. > Section 5 correctly identifies two conditions: both peers must support the > extension AND at least one non-compromised authentication key must be used in > the protocol run. The opening of Section 9 omits the second condition, which > is the substantive one that the rest of Section 9 spends several paragraphs > analyzing (PSK, EAP, etc.). I would suggest aligning it with the Section 5 > language. The intention of this sentence is to stress that *both* peers must implement this extension for the protection to work (it is insufficient if only one peer implements it). And the 1st sentence of the next para says about the non-compromised credentials: As pointed out in Section 5, a critical condition for downgrade prevention to work is that at least one non-compromised authentication key is used in the protocol run. We believe that the current text and the pointer to the Section 5 are sufficient. > --- > > Section 5 note — important limitation not cross-referenced in Section 9: > > 318 > | This mechanism only detects tampering with the IKE_SA_INIT > 319 > | transcript. It does not change the transform-selection rules > 320 > | for the responder. In particular, it does not by itself prove > 321 > | that the strongest mutually supported cryptographic algorithms > 322 > | were selected. That property depends on responder selection > 323 > | policy, which remains governed by [RFC7296] and local > 324 > | configuration. > > This limitation — that the extension authenticates the final > IKE_SA_INIT transcript, but cannot prevent an attacker from first using a > forged INVALID_KE_PAYLOAD to force a retry on a weaker key exchange, thereby > influencing what that final transcript contains — is security-relevant and > belongs in Section 9. Readers who consult Security Considerations directly to > assess the residual attack surface will miss this caveat entirely. I would > suggest adding a paragraph in Section 9 that summarizes this limitation and > cross-references Section 5. This text is moved to Section 9. > --- > > Section 8 — attack indistinguishability not noted: > > 427 > Deployments that rely on this mechanism for downgrade resistance > 428 > should provide a local policy to require successful negotiation of > 429 > this extension and to abort the connection otherwise. > > This section is the entirety of the operational guidance. In my view, it > would benefit from noting — consistent with what Section 5 says — that when > the mechanism detects a downgrade attempt, the resulting authentication > failure is indistinguishable from any other authentication failure (incorrect > credential, configuration mismatch, and so on). This has direct operational > consequence: operators cannot distinguish a downgrade attack from a > misconfiguration, so logging and alerting on these failures carries limited > diagnostic value. Good point, thank you. We used your proposed text and updated the Operational Considerations with it. New version of the draft: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/08/ The ditt: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-downgrade-prevention-08 Regards, Chris & Valery. _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
