Thx Kyle, addressed in -06. I did not address the first comment because it is the Introduction and the details are explained in the later section of the doc.
-----Original Message----- From: Kyle Rose via Datatracker <[email protected]> Sent: Tuesday, June 9, 2026 1:00 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] draft-ietf-ipsecme-ikev2-mlkem-05 ietf last call Tsvart review 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. Document: draft-ietf-ipsecme-ikev2-mlkem Title: Post-quantum Key Exchange with ML-KEM in the Internet Key Exchange Protocol Version 2 (IKEv2) Reviewer: Kyle Rose Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC [email protected] if you reply to or forward this review. This document is Ready with Nits. Nits: * "Other than combining the security of a well-established algorithm with relatively new quantum-resistant algorithms, another use of a PQ/T Hybrid key exchanges in IKEv2 is to prevent fragmentation of key exchanges with the high security parameter of ML-KEM which may not fit in common network packet payload sizes." It is unclear how the use of hybrid key exchanges results in ML-KEM parameters that allow the key share to fit within a typical MTU. (I can obviously guess, but this should nonetheless be clarified for those readers not intimately familiar with IKEv2 or RFC 9370.) Other comments: * It seems like the susceptibility of IKEv2 to downgrade attacks by active MitMs should be described and discussed in one place (and hopefully motivate the development of an IKEv3 not vulnerable to this kind of attack) rather than resulting in the same boilerplate in every document describing a new security parameter. * Is the information in appendix A required in order to implement this specification? It might be, but it's unclear on my reading. If it is required, then it should be in the main text of the document, not in an appendix. _______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
