Thread-Topic: [IPsec] WGLC for draft-ietf-ipsecme-ikev2-mlkem
From: "Kampanakis, Panos" <kpanos@amazon.com>
To: Valery Smyslov <smyslov.ietf@gmail.com>, "ipsec@ietf.org" <ipsec@ietf.org>
Thread-Index: AQHcE4aSKxowUsBdFEqYVVpuCzxdbLR3x5OAgBG7/3CAApVFAIAEiiGg
Date: Sat, 13 Sep 2025 04:15:38 +0000
Message-ID: 
 <DM5PR18MB23264EB9398B19D5C824866DAB0BA@DM5PR18MB2326.namprd18.prod.outlook.com>
References: <26792.41553.509374.327287@fireball.acr.fi>
 <008501dc17f7$512ff290$f38fd7b0$@gmail.com>
 <DM5PR18MB23268B2CD6C793964F3A8534AB0CA@DM5PR18MB2326.namprd18.prod.outlook.com>
 <053401dc221f$f36d2820$da477860$@gmail.com>
In-Reply-To: <053401dc221f$f36d2820$da477860$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?us-ascii?Q?tOe4ugsVBoZwf5V1KfzwgSM0lqeonUCun09yOY5276/KShE24ND2O7xNhCv6?=
 =?us-ascii?Q?fqxrflxOcq+E8GoC4X3JxTJilhSCZq9cvTrCSG8Yx143BR9x7zwbyl9eFBOO?=
 =?us-ascii?Q?9CSCdh9kOFwoq7K8/65Cag08zzWW4VtLv75M3oALwJXy/sLjL1rdfnkKm65+?=
 =?us-ascii?Q?YbNMKlMpy7tUHn0yb/qBYW66aZ9cuy7W8G/VukNNsYoM+ciV+MwVw9J8OloS?=
 =?us-ascii?Q?2yWiwAPetjknq+9wBua145uMQrVuNeavRFWWJyDndsuYFabHTisbx3l4gE3D?=
 =?us-ascii?Q?ugTHp33I2KPuHyWi3N+kBR55kViGYimGQF71cJTLLRLyvFgQaJxpMHlof69s?=
 =?us-ascii?Q?hNAlfOtE3JDiVdjXnjrc8JpHUfcrB8qPdY4b7RYRBwJQ1iRcSfSTwSsPoMlJ?=
 =?us-ascii?Q?0y/fzbQVO3xLkaqHy59glA8yUWLvR+PFvaUMsaw49amJG5Gs1uGKU3u7TWuC?=
 =?us-ascii?Q?Uz8OCr1NkOFvwlccnc/rlX1Snn4t1bleg62VZCRIw0Si18A9SgysB5bNx6W8?=
 =?us-ascii?Q?QTm04193sR18p+Xf7XX6HM12NPc3dp07s5C+x5fMVxzpEnhqW59PFkVqM2Mw?=
 =?us-ascii?Q?nR3nlc3w7SMLfSwe4CkA9vQaqR4kkgtyxba4rTVFE/BoupvuzjASLNoBH4qE?=
 =?us-ascii?Q?itYU/kgovNH88kCJLqZBb/DqDX+4RMFo1H3X8TpAMS8CACFYXpTC9H1rkXkh?=
 =?us-ascii?Q?NfmEG5w17QhyzZQpPj4i2G8ZY+ZpL6shSPq/pRV+XAENOoJ+SRLyiNyRWJp4?=
 =?us-ascii?Q?Lsd70/rZ6HqHRrcLoov79l+ptrv3bFXHta09+NmNFUdcVmf8+y8TzS8qsNYr?=
 =?us-ascii?Q?2GzhpnpClI1RKD/n7sVTczkWIZjZtRmD1bAEInJs0NUViGhzuSoYDWf/dgMI?=
 =?us-ascii?Q?+1nlNfzvAQ2b2OeFPX8BiAV7J8AHVTE8BEusOzOOq6LSixYH27wVCNreqO6y?=
 =?us-ascii?Q?KENF0IZLWozJi3tmDWU1gUl8wlZ+ibV30reYQfMOgs80acSH9A3oevdT+Gnj?=
 =?us-ascii?Q?ygO0oKbzHp2QRgVpAW50Oy+8SDyMXcDF/KezetQTKgSpyc2JqeiViUgjrF8b?=
 =?us-ascii?Q?Jo99ueb6zcGLE+8uJ1ZVw4crkE04txxCjT7YPQSYGI9lNDl1LFT18xn5e2jS?=
 =?us-ascii?Q?bpsSNWvol4HFrjleFc+jFHucWKXYD6IS58j6Z6m5ca8EcnT7m2t9Pi7OOxM5?=
 =?us-ascii?Q?cvzTdb1RoXPA+hmdxbDxWhXzTL1y67fmTCW59nhuRzHzOHeCXM86mgS9+va9?=
 =?us-ascii?Q?B9D3kVjEQ1gNyJ6yOTI5AdGATAxueSocS26/kUVtuxa2LBnO5HU9TbqUyzDS?=
 =?us-ascii?Q?3PPCxVJUD/COfQz6NBO5Ovya+vHbC9IrUF1ZMUBFpkC2kEb5bUA/pJzngSLl?=
 =?us-ascii?Q?wilXflRHzUglvpg2cinHVECzUIeyb9oy5U7XHWePKUa98YnN26GMqHZ+4lrC?=
 =?us-ascii?Q?/QujovO6sJ0N8yZcYBbs/D95+Wx09dWlDEbujYItmRFy2dm7rVQ5facdj1x4?=
 =?us-ascii?Q?i/urOgv0AqLwjGfNOhJaZStvAbW37BrmgK4ao9KlB+k3V2Uiny8zFzfXnysw?=
 =?us-ascii?Q?rIbz0WyVDf5/1iDjhyK0ZFpcTzM5hYj0uzLZ9AS4xX++5NAQ1d5lBuq7wJo8?=
 =?us-ascii?Q?ET9jSsGwUGwXFoxO9SmtAps=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: DM5PR18MB2326.namprd18.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 74ebd669-b56f-40e6-80e2-08ddf27c3245
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Sep 2025 04:15:38.9149
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5280104a-472d-4538-9ccf-1e1d0efe8b1b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 iiN6DPT2DqyyFpe9zpTPdHoruW9zoRV3BbS4B9/nipA0IytJHtdh9Y+DV7LO4qm11XGBy8tXQaqvP4bxauZMPQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA3PR18MB5556
X-OriginatorOrg: amazon.com
Message-ID-Hash: V6G4S6UUBGOOILIC2JAYIUYDCIE36MNE
X-Message-ID-Hash: V6G4S6UUBGOOILIC2JAYIUYDCIE36MNE
X-MailFrom: prvs=3445896ed=kpanos@amazon.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-ipsec.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BIPsec=5D_Re=3A_WGLC_for_draft-ietf-ipsecme-ikev2-mlkem?=
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ipsec/wnfXyLGkYL8XZzbMf3WPwxSSIHo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Owner: <mailto:ipsec-owner@ietf.org>
List-Post: <mailto:ipsec@ietf.org>
List-Subscribe: <mailto:ipsec-join@ietf.org>
List-Unsubscribe: <mailto:ipsec-leave@ietf.org>

Thanks again Valery. This https://github.com/csosto-pk/pq-mlkem-ikev2/commi=
t/0cc0b25d2d8613c554b09f5cbfbc6da3ca658924 should cover it.=20

-----Original Message-----
From: Valery Smyslov <smyslov.ietf@gmail.com>=20
Sent: Wednesday, September 10, 2025 2:56 AM
To: Kampanakis, Panos <kpanos@amazon.com>; ipsec@ietf.org
Subject: RE: [EXTERNAL] [IPsec] WGLC for draft-ietf-ipsecme-ikev2-mlkem

CAUTION: This email originated from outside of the organization. Do not cli=
ck links or open attachments unless you can confirm the sender and know the=
 content is safe.



Hi Panos,

> Hi Valery, thank you.
>
> I incorporated all of these in https://github.com/csosto-pk/pq-mlkem-
> ikev2/commit/b627d392eaccd3ee1f82e77ac618867ee2358efa (minor some nits wh=
ich I fixed afterwards).

thank you for this update. I think we are almost there. Just a few more con=
cerns, please see below.

> Note I trimmed down the last paragraph of the Sec Considerations as=20
> suggested but I did not remove it. I wanted to keep the option for=20
> cases where the initiators and responder must co-exist with legacy and=20
> there is predistributed knowledge of the identities that have been upgrad=
ed. It is not a flexible option, but I wanted to lay out the option for lar=
ge deployments.

OK.

> Also, please confirm that you are OK with the existing text.
>
> > If the checks fail, the responder SHOULD send a Notify payload of=20
> > type INVALID_SYNTAX as a response to the request from initiator.

This is OK.

> which I kept as is.

Regarding the text:

        <xref target=3D"I-D.ietf-ipsecme-ikev2-qr-alt"> also enables a nego=
tiation of PPK and ML-KEM
        in a single message without an aditional round-trip penalty.

I think that it somewhat lacks a context for readers (my fault, I was too b=
rief proposing it).
I propose to use the following text (something along the lines):

        As alternative, <xref target=3D"I-D.ietf-ipsecme-ikev2-qr-alt"> can=
 also be used for mixing
        pre-shared keys in IKEv2, as it provides better security properties=
 than <xref target=3D"RFC8784" />
        and, since negotiation of PPK can be combined with additional key e=
xchange performing ML-KEM,
        extra round trip penalty can be avoided.


Regarding the text:

        Afterwards the peers can perform more IKE_INTERMEDIATE key exchange=
s if necessary
        and then continue to the IKE_AUTH exchange [...]

Please, remove "key" from this sentence - IKE_INTERMEDIATE exchanges can be=
 used for various purposes besides key exchange.


Regarding the text:

        The initiator <bcp14>MAY</bcp14> also send a Delete Payload in a ne=
w INFORMATIONAL
        exchange for the responder to remove the SA.

This needs a clarification. If the error occurs before IKE SA is created (i=
.e. in the IKE_INTERMEDIATE), then the initiator cannot start INFORMATIONAL=
 exchange with Delete payload - it just does not have session keys yet. It =
can start unprotected INFORMATIONAL, but it will be ignored by responder.
Thus, it is not possible to (and there is no point) to do this in this case=
.

On the other hand, if the error occurs in the IKE_FOLLOWP_KE during a rekey=
 or establishing an additional Child SA, then the Initiator can delete exis=
ting IKE SA in this case.
I believe that it even MUST do this: otherwise some unpleasant situations m=
ay happen, if, for example, the error occurs in the last IKE_FOLLOWP_KE mes=
sage, so that the responder has already created a new SA. In this case the =
initiator must delete the current IKE SA. And if this was an IKE SA rekey, =
then the initiator should also delete a new IKE SA, but it cannot - due to =
the error it cannot calculate the keys for a new IKE SA. This is unpleasant=
 situation for which  IKEv2 provides no good ways to recover from (it may h=
appen even in base IKEv2 with sole CREATE_CHILD_SA).
The only way to recover is to start creating IKE SA from scratch sending IN=
ITIAL_CONTACT.

I don't think all these speculations must be in the draft, just clarify, th=
at in case the error occurs in the CREATE_CHILD_SA or IKE_FOLLOWUP_KE excha=
nges, then the initiator MUST delete existing IKE SA by sending a Delete pa=
yload in a new INFORMATIONAL exchange.

(similar text is present in the draft, but is commented out).

Regards,
Valery.

> -----Original Message-----
> From: Valery Smyslov <smyslov.ietf@gmail.com>
> Sent: Thursday, August 28, 2025 4:40 AM
> To: 'Tero Kivinen' <kivinen@iki.fi>; ipsec@ietf.org
> Cc: draft-ietf-ipsecme-ikev2-mlkem@ietf.org
> Subject: RE: [EXTERNAL] [IPsec] WGLC for=20
> draft-ietf-ipsecme-ikev2-mlkem
>
> CAUTION: This email originated from outside of the organization. Do=20
> not click links or open attachments unless you can confirm the sender and=
 know the content is safe.
>
>
>
> Hi,
>
> I read the document and I think it is ready for publication.
> I also strongly believe that it is the time to request official code poin=
ts from IANA.
>
> There are still some issues that should be addressed before requesting of=
 publication.
>
> 1. Abstract.
>
> The abstract is not consistent with the body of the document - it only=20
> talks about using ML-KEM as an additional KE method, while the document a=
llows both standalone and hybrid use of ML-KEM.
>
> 2. Section 1.
>
>    To address this concern, the Mixing Preshared Keys in IKEv2
>    specification [RFC8784] introduced Post-quantum Preshared Keys as a
>    temporary option for stirring a pre-shared key of adequate entropy in
>    the derived Child SA encryption keys in order to provide quantum-
>    resistance.  This specification can be used in conjunction with PPK
>    as defined in [RFC8784].
>
> I think that draft-ietf-ipsecme-ikev2-qr-alt should also be referenced=20
> in this para, as it has advantages over
> RFC8784 and is even more suited for use with hybrid PQ KE, since=20
> negotiation of PPK and ML-KEM KE can be combined in a single IKE_INTERMED=
IATE - no additional round trip penalty.
>
> 3. Section 1.2.
>
>    ML-KEM-512, ML-KEM-768 and ML-KEM-1024 key exchanges will not have
>    material performance impact on IKEv2/IPsec tunnels which usually stay
>    up for long periods of time and transfer sizable amounts of data.
>
> Perhaps s/material/significant? Or noticeable?
>
> 4. Section 2.1.
>
>    Afterwards the peers continue to the
>    IKE_AUTH exchange phase as defined in Section 3.3.2 of the
>    Intermediate Exchange in IKEv2 specification [RFC9242].
>
> This sentence must be corrected since peers may have more=20
> IKE_INTERMEDIATE exchanges to perform after completing the one with ML-KE=
M before going to IKE_AUTH.
>
> 5. Section 2.1.
>
>    ML-KEM can also be used to create or rekey a Child SA or rekey the
>    IKE SA by using a IKE_FOLLOWUP_KE message after a CREATE_CHILD_SA
>    message.
>
> s/message/exchange (2 times)
>
> 6. Section 2.1.
>
>    ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP
>    packet sizes larger typical network MTUs (1500 bytes).
>                                ^^^^
>
> Is not "than" is missed here?
>
> 7. Section 2.1.
>
>    ML-KEM-1024 Key Exchange Method
>    identifier TBD37 SHOULD NOT be used in IKE_SA_INIT messages which
>    could exceed typical network MTUs and cannot be IKEv2 fragmented.
>
> A clarification should be added along the lines "unless IP=20
> fragmentation is known not to be an issue (e.g., when reliable transport =
is used for IKE [RFC9329], [draft-smyslov-ipsecme-ikev2-reliable-transport]=
)".
>
> 8. Section 2.3.
>
>    If the check fails, the initiator MUST
>    reject the ciphertext and MUST fail the exchange.  In this case, the
>    initiator MAY send a Notify payload of type INVALID_SYNTAX to the
>    responder as a separate INFORMATIONAL exchange, usually with no other
>    payloads.  This is an exception for the general rule of not starting
>    new exchanges based on errors in responses.
>
> I think this is a bad idea, not only because it violates RFC 7296=20
> Section 2.21, but also because the responder has no clue to associate=20
> the received error notification with the exchange containing the cipherte=
xt, which it thinks is completed with no error.
> I think that the proper way to handle this situation for the initiator=20
> is to log the error and just to stop creating new IKE SA if it is not=20
> yet created (i.e. not to initiate IKE_AUTH or next IKE_INTERMEDIATE)=20
> or to send a Delete payload in a new INFORMATIONAL exchange if the IKE=20
> SA is deemed to be already created by responder (e.g. if an error occurre=
d in the last IKE_FOLLOWUP_KE message when no more exchanges are expected t=
o complete the rekey).
>
> 9. Section 3.
>
>    Likewise, if the initiator knows
>    out-of-band that a responder supports ML-KEM, it SHOULD abort the
>    negotiation if the responder selects a proposal that doesn't include
>    ML-KEM.
>
> If the initiator knows beforehand that the responder supports ML-KEM,=20
> then the easier way for the initiator to handle this situation is to=20
> include _only_ proposals with ML-KEM into the SA payload (thus, restricti=
ng the possible responder's choice).
>
> 10. Section 3, last para.
>
> I'd rather to remove this para (or at least to shorten it). The=20
> initiator usually knows (or at least assumes) who responder is, it even s=
ends the perceived responder's identity in IKE_AUTH.
> In this case, if the initiator knows the responder's capabilities=20
> beforehand, then it can avoid all this hassle with postponed PQ KE by=20
> simply only offering proposals with ML-KEM. The downgrade attack is=20
> only possible if the initiator does not know the responder's capabilities=
 when it starts creating IKE SA and thus offers wider options (including th=
ose w/o ML-KEM).
>
> 11. Section 4.
>
> Since official code points are already allocated, please replace=20
> TBD35, TBD36 and TBD37 with actual values (35,
> 36 and 37). This also should be done throughout the document.
>
> Also please remove the last row from the table:
>
>     +---------+-------------+--------+-------------------+------------+
>     | 38-1023 | Unassigned  |        |                   |            |
>    =20
> +---------+-------------+--------+-------------------+------------+
>
> as this is now what is requested (range of unassigned values are=20
> maintained by IANA and can be consumed before this draft is published).
>
> Regards,
> Valery.
>
> > This will start two week WGLC for the draft-ietf-ipsecme-ikev2-mlkem=20
> > [1]. This last call will end at 2025-09-07. If you have any comments=20
> > about the draft send them to the WG list.
> >
> > [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/
> > --
> > kivinen@iki.fi
> >
> > _______________________________________________
> > IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to=20
> > ipsec-leave@ietf.org