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 which
> I fixed afterwards).
thank you for this update. I think we are almost there. Just a few more
concerns, please see below.
> Note I trimmed down the last paragraph of the Sec Considerations as suggested
> but I did not remove it. I wanted
> to keep the option for cases where the initiators and responder must co-exist
> with legacy and there is
> predistributed knowledge of the identities that have been upgraded. It is not
> a flexible option, but I wanted to lay
> out the option for large 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 type INVALID_SYNTAX as a response to the request from
> > initiator.
This is OK.
> which I kept as is.
Regarding the text:
<xref target="I-D.ietf-ipsecme-ikev2-qr-alt"> also enables a
negotiation 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 brief
proposing it).
I propose to use the following text (something along the lines):
As alternative, <xref target="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="RFC8784" />
and, since negotiation of PPK can be combined with additional key
exchange performing ML-KEM,
extra round trip penalty can be avoided.
Regarding the text:
Afterwards the peers can perform more IKE_INTERMEDIATE key exchanges 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 new
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 existing IKE SA in this
case.
I believe that it even MUST do this: otherwise some unpleasant situations may
happen,
if, for example, the error occurs in the last IKE_FOLLOWP_KE message, 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 happen even in base IKEv2 with sole
CREATE_CHILD_SA).
The only way to recover is to start creating IKE SA from scratch sending
INITIAL_CONTACT.
I don't think all these speculations must be in the draft, just clarify,
that in case the error occurs in the CREATE_CHILD_SA or IKE_FOLLOWUP_KE
exchanges,
then the initiator MUST delete existing IKE SA by sending a Delete payload in a
new
INFORMATIONAL exchange.
(similar text is present in the draft, but is commented out).
Regards,
Valery.
> -----Original Message-----
> From: Valery Smyslov <[email protected]>
> Sent: Thursday, August 28, 2025 4:40 AM
> To: 'Tero Kivinen' <[email protected]>; [email protected]
> Cc: [email protected]
> Subject: RE: [EXTERNAL] [IPsec] WGLC for draft-ietf-ipsecme-ikev2-mlkem
>
> CAUTION: This email originated from outside of the organization. Do 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 points
> 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 talks
> about using ML-KEM as an additional
> KE method, while the document allows 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 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.
>
> 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 IKE_INTERMEDIATE
> exchanges to perform after
> completing the one with ML-KEM 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 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 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).
>
> 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, 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).
>
> 10. Section 3, last para.
>
> 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).
>
> 11. Section 4.
>
> 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.
>
> Also please remove the last row from the table:
>
> +---------+-------------+--------+-------------------+------------+
> | 38-1023 | Unassigned | | | |
> +---------+-------------+--------+-------------------+------------+
>
> as this is now what is requested (range of unassigned values are 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
> > [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/
> > --
> > [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]
