Hi John,
authors didn't think (or realize) that this is a significant change to the document. As Yoav pointed out, the document should have *some* normative reference to FrodoKEM and since ISO finalized it just before the IETF meeting, the authors decided that this is currently the most authoritative reference, thus listed it as normative. Generally speaking, it is always better to have a stable document as a normative reference and formally draft-longa-cfrg-frodokem is not stable until it becomes the RFC (that we wish to happen ASAP). Anyway, we understand your concerns about paywalled documents and it is not a big deal to make ISO reference informative and draft-longa-cfrg-frodokem normative, (as, for example, in draft-smyslov-lamps-frodokem-certificates-03) if the WG thinks this is more appropriate. Regards, Valery. Paul Koning wrote: >Surely there is a common IETF policy on how to deal with this, Yes, once a document is adopted by a working group, the authors are editors acting on behalf of the WG. Significant changes after adoption are expected to be discussed on the WG mailing list and should have working group consensus (or at least no significant unresolved objection) before being incorporated. Cheers, John Preuß Mattsson From: Koning, Paul <[email protected]> Date: Wednesday, 22 July 2026 at 19:39 To: John Mattsson <[email protected]>; Yoav Nir <[email protected]> Cc: [email protected] <[email protected]> Subject: RE: [IPsec] Re: I-D Action: draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-01.txt You don't often get email from [email protected]. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> Outside standards have been referenced for ages, certainly ISO and probably others. Surely there is a common IETF policy on how to deal with this, in particular the unfortunate practice of many other standards bodies to charge significant sums of money for their standards. paul Internal Use - Confidential From: John Mattsson <[email protected]> Sent: Wednesday, July 22, 2026 1:10 PM To: Yoav Nir <[email protected]> Cc: [email protected] Subject: [IPsec] Re: I-D Action: draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-01.txt [EXTERNAL EMAIL] Yoav Nir wrote: >It makes sense that any Using algorithm A in IKEv2 draft is going to have algorithm A as a normative reference Yes. The adopted version had draft-longa-cfrg-frodokem as a normative reference. As I said, I strongly oppose this change. Making a paywalled cryptographic specification a normative reference is a very significant change. I do not think the IETF should adopt or publish any documents with normative references to paywalled cryptography. I therefore suggest that the authors submit a -02 revision reverting it. Cheers, John Preuß Mattsson From: Yoav Nir <[email protected] <mailto:[email protected]> > Date: Wednesday, 22 July 2026 at 18:57 To: John Mattsson <[email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-01.txt [with no hats] It makes sense that any Using algorithm A in IKEv2 draft is going to have algorithm A as a normative reference, because you cant implement the new document without using the old document. This is also what we did with RFC 8031 and 8420 - the last two times we had a new algorithm in an IPsecME document. Yoav On 22 Jul 2026, at 18:58, John Mattsson <[email protected] <mailto:[email protected]> > wrote: The -01 version makes the paywalled ISO reference normative. In the adopted -00 version, it was only informative. Keeping the paywalled reference informative was a requirement for my support of adoption. I strongly oppose this change, which, to my knowledge, has not been discussed on the IPsec mailing list. Cheers, John Preuß Mattsson On 2026-07-04, 17:42, "[email protected] <mailto:[email protected]> " <[email protected] <mailto:[email protected]> > wrote: Internet-Draft draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-01.txt is now available. It is a work item of the IP Security Maintenance and Extensions (IPSECME) WG of the IETF. Title: Post-quantum Key Exchange in IKEv2 with FrodoKEM Authors: Guilin Wang Leonie Bruckert Valery Smyslov Meiling Chen Name: draft-ietf-ipsecme-hybrid-kem-ikev2-frodo-01.txt Pages: 16 Dates: 2026-07-04 Abstract: FrodoKEM is an unstructured lattice based Key Encapsulation Mechanism (KEM), standardized by ISO. Compared to ML-KEM, it is considered with more conservative security. This draft specifies how to use FrodoKEM by itself or as an additional key exchange in IKEv2 along with a traditional key exchange. These options enable to negotiate IKE and Child SA keys that are safe against a Cryptographically Relevant Quantum Computer (CRQC). The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-hybrid-kem-ikev2-frodo/ [datatracker.ietf.org] <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-ipse cme-hybrid-kem-ikev2-frodo/__;!!LpKI!jWyg0WpnTQWxc_G82C7WUnNb2O_j67FIJJj7SIS xYkeEVT4rQewo3vxe57ezuzwBM3ehLes1YHkA-eS9UARdT32HK8_abvKu$> There is also an HTMLized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-hybrid-kem-ikev2-fr odo-01 [datatracker.ietf.org] <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf -ipsecme-hybrid-kem-ikev2-frodo-01__;!!LpKI!jWyg0WpnTQWxc_G82C7WUnNb2O_j67FI JJj7SISxYkeEVT4rQewo3vxe57ezuzwBM3ehLes1YHkA-eS9UARdT32HK2Le0ljy$> A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-ipsecme-hybrid-kem-ikev 2-frodo-01 [author-tools.ietf.org] <https://urldefense.com/v3/__https:/author-tools.ietf.org/iddiff?url2=draft- ietf-ipsecme-hybrid-kem-ikev2-frodo-01__;!!LpKI!jWyg0WpnTQWxc_G82C7WUnNb2O_j 67FIJJj7SISxYkeEVT4rQewo3vxe57ezuzwBM3ehLes1YHkA-eS9UARdT32HK6OerxEr$> Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ IPsec mailing list -- [email protected] <mailto:[email protected]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
