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/
> --
> kivi...@iki.fi
>
> _______________________________________________
> IPsec mailing list -- ipsec@ietf.org
> To unsubscribe send an email to ipsec-le...@ietf.org
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
