Looks good to me. Nits.
Abstract: "some kind" -> "particular" sound a bit better to my ear. Introduction: Perhaps use "SIGn-and-MAc (SIGMA)" as SIGMA protocol can be confused nowadays with the class to which Schnorr belongs. The introduction feels like it's missing a final sentence. Something like "In this document we'll first describe how authentication works now (§3); to which attack it's vulnerable (§4), ..." §3. "Peers sign (or MAC) some blobs". Is blobs the standard terminology? For clarity I'd add "the initiator, but not the responder, authenticates the IKE_SA_INIT [...]" §4. What do you mean to say with 'for some definition of "strong" and "weak"'? Isn't the next sentence "the attacker must be able to break "weak" key exchang methods in real time" enough? §5. "aims to detect". Why "aims"? It does detect it. Why would you support the extension and not use it? I'd write something like "This document defines an extension that when supported by both peers prevents the downgrade attacks described in [...]. The peers achieve this by hashing in both sent and received messages when the extension is supported by both. This ensures that if both peers support the extension and at least [...]" §6 Is there any potential confusion on how to split the concatenation RealMessage1 | RealMessage2 | Nonce*Data | MACedIDFor*? §8. Refer to the section where you describe the downgrade attack. On Thu, Feb 26, 2026 at 7:55 PM Christopher Patton <cpatton= [email protected]> wrote: > Hi all, I just wanted to add that we implemented this feature in our > internal implementation of IKEv2 and have confirmed interop with > strongswan's experimental branch: > > git clone --depth 1 --branch downgrade-prevention > https://github.com/strongswan/strongswan.git > > One thing we noticed is that the draft doesn't explicitly specify how to > handle a malformed IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification (i.e., one > that has a non-empty payload, a non-zero Protocol ID, or a non-zero SPI > Size [1]). Our responder handles this case by sending an INVALID_SYNTAX > error. (We don't implement an initiator.) My understanding is that this > behavior is allowed by IKEv2, but other behaviors are allowed as well. If > my understanding is correct, then I don't see a need to make the behavior > explicit. > > Apart from that, I have no more changes for the WG to consider and I think > this is ready to go. We look forward to getting a codepoint! > > Best, > Chris P. > > [1] > https://www.ietf.org/archive/id/draft-ietf-ipsecme-ikev2-downgrade-prevention-01.html#section-6-1 > > > On Mon, Feb 16, 2026 at 9:49 AM Tero Kivinen via Datatracker < > [email protected]> wrote: > >> This message starts a WG Last Call for: >> draft-ietf-ipsecme-ikev2-downgrade-prevention-01 >> >> This Working Group Last Call ends on 2026-03-02 >> >> Abstract: >> This document describes an extension to the Internet Key Exchange >> protocol version 2 (IKEv2) that aims to prevent some kinds of >> downgrade attacks on this protocol by having the peers confirm they >> have participated in the same conversation. >> >> File can be retrieved from: >> >> Please review and indicate your support or objection to proceed with the >> publication of this document by replying to this email keeping >> [email protected] >> in copy. Objections should be explained and suggestions to resolve them >> are >> highly appreciated. >> >> Authors, and WG participants in general, are reminded of the Intellectual >> Property Rights (IPR) disclosure obligations described in BCP 79 [1]. >> Appropriate IPR disclosures required for full conformance with the >> provisions >> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. >> Sanctions available for application to violators of IETF IPR Policy can be >> found at [3]. >> >> Thank you. >> >> [1] https://datatracker.ietf.org/doc/bcp78/ >> [2] https://datatracker.ietf.org/doc/bcp79/ >> [3] https://datatracker.ietf.org/doc/rfc6701/ >> >> The IETF datatracker status page for this Internet-Draft is: >> >> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/ >> >> There is also an HTMLized version available at: >> >> https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-ikev2-downgrade-prevention-01 >> >> A diff from the previous version is available at: >> >> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-ikev2-downgrade-prevention-01 >> >> _______________________________________________ >> IPsec mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > IPsec mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
