There is no -06 on the data tracker yet. Please let me know when it's been posted so I can take a gander at the diff.
On Tue, Jun 9, 2026 at 8:12 AM Kampanakis, Panos <[email protected]> wrote: > 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]
