On Mon, Mar 2, 2026 at 1:32 PM Valery Smyslov <[email protected]>
wrote:

> Hi Bas,
>
>
>
> thank you for your comments.
>
>
>
> I created a PR that reflects most of your suggestions:
>
> https://github.com/smyslov/ikev2-downgrade-prevention/pull/19
>
>
>
> Please also see inline/
>
>
>
> 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), ..."
>
>
>
>          This is more in a tradition of academic papers J I personally
> don’t think this is needed, however I agree tat perhaps the Introduction
> is too short.
>

Didn't mean to say it needs that specific sentence, just that it'd benefit
from some sentence to be a bit less jarring. :)


    §6 Is there any potential confusion on how to split the concatenation
> RealMessage1 | RealMessage2 | Nonce*Data | MACedIDFor*?
>

>
>          This comment I did not understand, can you clarify?
>

I think Chris understood: it's about whether there could be multiple ways
to arrive at the same concatenation.

PR looks good, thanks!

 Bas


>
> §8. Refer to the section where you describe the downgrade attack.
>
>
>
>          Regards,
>
>          Valery.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> 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]

Reply via email to