Hi Thom, thanks for bringing this up.
On Fri, Feb 20, 2026 at 06:26:11 -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC8784, > "Mixing Preshared Keys in the Internet Key Exchange Protocol Version 2 > (IKEv2) for Post-quantum Security". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid8775 > > -------------------------------------- > Type: Technical > Reported by: Thom Wiggers <[email protected]> > > Section: 6 > > Original Text > ------------- > In addition, the policy SHOULD be set to negotiate only quantum- > secure symmetric algorithms; while this RFC doesn't claim to give > advice as to what algorithms are secure (as that may change based on > future cryptographical results), below is a list of defined IKEv2 and > IPsec algorithms that should not be used, as they are known to > provide less than 128 bits of post-quantum security: > > * Any IKEv2 encryption algorithm, PRF, or integrity algorithm with a > key size less than 256 bits. > > * Any ESP transform with a key size less than 256 bits. > > * PRF_AES128_XCBC and PRF_AES128_CBC: even though they can use as > input a key of arbitrary size, such input keys are converted into > a 128-bit key for internal use. > > Corrected Text > -------------- > In general, the discussion on Grover's algorithm in the security > considerations needs to be revisited. Since the document was published, > the cryptographic community has come to the wide agreement that Grover's > algorithm has extremely large implementation cost which practically > negates its theoretical advantage over classical computers. > > As such, using (good) 128-bit secure algorithms is just fine. While I agree with the gist of this text, I would still like to see a clear reference explaining why you propose this change. That would help non‑cryptographers — or at least ESP engineers — understand the rationale. Please also be explicit about whether the reference you rely on is intended to be normative or only informative. I find the NIST wording on this topic somewhat unclear, and since this erratum is being proposed many years after the original RFC, it is important that the justification is precise. Without clear and concrete references, I recommend not accepting this erratum. And more curious question. I have to wonder is NIST sticking with 128-bit security primarily because AES has a fixed 128-bit block size? While AES 256 is sort still mangling of AES128. Is the research quantifying Grover's impracticality focused only on AES and not other symmetric primitives used in IPsec? Did they review also to chacha poly. As t is a Should in RFC 8221. It would nice to cover this too. > > Notes > ----- > This also transitively affects RFC 9867 which points to this RFC's security > considerations. > > Instructions: > ------------- > This erratum is currently posted as "Reported". (If it is spam, it > will be removed shortly by the RFC Production Center.) Please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > will log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8784 (draft-ietf-ipsecme-qr-ikev2-11) > -------------------------------------- > Title : Mixing Preshared Keys in the Internet Key Exchange > Protocol Version 2 (IKEv2) for Post-quantum Security > Publication Date : June 2020 > Author(s) : S. Fluhrer, P. Kampanakis, D. McGrew, V. Smyslov > Category : PROPOSED STANDARD > Source : IP Security Maintenance and Extensions > Stream : IETF > Verifying Party : IESG > > _______________________________________________ > 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]
