From: "Valery Smyslov" <smyslov.ietf@gmail.com>
To: "'Tero Kivinen'" <kivinen@iki.fi>,
	<ipsec@ietf.org>
References: <26792.41553.509374.327287@fireball.acr.fi>
 <008501dc17f7$512ff290$f38fd7b0$@gmail.com>
In-Reply-To: <008501dc17f7$512ff290$f38fd7b0$@gmail.com>
Date: Thu, 28 Aug 2025 11:47:01 +0300
Message-ID: <008601dc17f8$536a83d0$fa3f8b70$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQI1Sv5REM0iGXttxRBfjO79bNR+YQJJfqNGs7MN5lA=
Content-Language: ru
Message-ID-Hash: GZTXBA5GXZ4M67H3YPWTKFBY3VNNJ6NX
CC: draft-ietf-ipsecme-ikev2-mlkem@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BIPsec=5D_Re=3A_WGLC_for_draft-ietf-ipsecme-ikev2-mlkem?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/ipsec/HH4EX2aVCP7-X5VaphbajPz5cXo>

> Hi,
>=20
> 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 =
points from IANA.

OOPS, code points are already allocated, they are just not mentioned in =
the draft=20
that made me wrongly thinking that they are not yet requested.
Sorry for confusion.

Regards,
Valery.

> There are still some issues that should be addressed before requesting =
of
> publication.
>=20
> 1. Abstract.
>=20
> The abstract is not consistent with the body of the document - it only =
talks about
> using ML-KEM as an additional KE method, while the document allows
> both standalone and hybrid use of ML-KEM.
>=20
> 2. Section 1.
>=20
>    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].
>=20
> I think that draft-ietf-ipsecme-ikev2-qr-alt should also be referenced =
in this para,
> as it has advantages over RFC8784 and is even more suited for use with =
hybrid
> PQ KE,
> since negotiation of PPK and ML-KEM KE can be combined in a single
> IKE_INTERMEDIATE -
> no additional round trip penalty.
>=20
> 3. Section 1.2.
>=20
>    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.
>=20
> Perhaps s/material/significant? Or noticeable?
>=20
> 4. Section 2.1.
>=20
>    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].
>=20
> This sentence must be corrected since peers may have more
> IKE_INTERMEDIATE exchanges to perform after completing the
> one with ML-KEM before going to IKE_AUTH.
>=20
> 5. Section 2.1.
>=20
>    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.
>=20
> s/message/exchange (2 times)
>=20
> 6. Section 2.1.
>=20
>    ML-KEM-768 and ML-KEM-1024 public keys and ciphertexts may make UDP
>    packet sizes larger typical network MTUs (1500 bytes).
>                                ^^^^
>=20
> Is not "than" is missed here?
>=20
> 7. Section 2.1.
>=20
>    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.
>=20
> A clarification should be added along the lines "unless IP =
fragmentation
> is known not to be an issue (e.g., when reliable transport is used for =
IKE
> [RFC9329], [draft-smyslov-ipsecme-ikev2-reliable-transport])".
>=20
> 8. Section 2.3.
>=20
>    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.
>=20
> I think this is a bad idea, not only because it violates RFC 7296 =
Section 2.21,
> but also because the responder has no clue to associate the received =
error
> notification with the exchange containing the ciphertext, which it =
thinks is completed
> with no error.
> I think that the proper way to handle this situation for the initiator =
is to log the error
> and just to stop
> creating new IKE SA if it is not yet created (i.e. not to initiate =
IKE_AUTH or next
> IKE_INTERMEDIATE)
> or to send a Delete payload in a new INFORMATIONAL exchange if the IKE =
SA is
> deemed to be already
> created by responder (e.g. if an error occurred in the last =
IKE_FOLLOWUP_KE
> message when no more
> exchanges are expected to complete the rekey).
>=20
> 9. Section 3.
>=20
>    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.
>=20
> If the initiator knows beforehand that the responder supports ML-KEM, =
then the
> easier
> way for the initiator to handle this situation is to include _only_ =
proposals
> with ML-KEM into the SA payload (thus, restricting the possible =
responder's
> choice).
>=20
> 10. Section 3, last para.
>=20
> I'd rather to remove this para (or at least to shorten it). The =
initiator usually
> knows (or at least assumes) who responder is,
> it even sends the perceived responder's identity in IKE_AUTH.
> In this case, if the initiator knows the responder's capabilities =
beforehand,
> then it can avoid all this hassle with postponed PQ KE by simply
> only offering proposals with ML-KEM. The downgrade attack is only
> possible if the initiator does not know the responder's capabilities
> when it starts creating IKE SA and thus offers wider options
> (including those w/o ML-KEM).
>=20
> 11. Section 4.
>=20
> Since official code points are already allocated, please replace =
TBD35, TBD36 and
> TBD37
> with actual values (35, 36 and 37). This also should be done =
throughout the
> document.
>=20
> Also please remove the last row from the table:
>=20
>     =
+---------+-------------+--------+-------------------+------------+
>     | 38-1023 | Unassigned  |        |                   |            =
|
>     =
+---------+-------------+--------+-------------------+------------+
>=20
> as this is now what is requested (range of unassigned values are =
maintained by
> IANA
> and can be consumed before this draft is published).
>=20
> Regards,
> Valery.
>=20
> > This will start two week WGLC for the draft-ietf-ipsecme-ikev2-mlkem
> > [1]. This last call will end at 2025-09-07. If you have any comments =
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 ipsec-leave@ietf.org