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).
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. 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. which I kept as is. -----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]
