Hi Antony, I did not actually want to “propose text”, only provide a comment: though the submit erratum forum calls my comment “Corrected Text”, note that I suggest revisiting the whole section. Some suggested references are e.g. the NIST FAQ [1] and this review by UK NCSC [2].
On your question “what about ChaCha20?”: Note that Grover search is a “black box” search algorithm. So its cost is mostly agnostic to the algorithm up to a constant factor (the depth of the circuit needed to implement AES). Cheers, Thom [1] "To protect against the threat of quantum computers, should we double the key length for AES now? (added 11/18/18)" @ https://csrc.nist.gov/projects/post-quantum-cryptography/faqs [2] https://csrc.nist.gov/csrc/media/Events/2024/fifth-pqc-standardization-conference/documents/papers/on-practical-cost-of-grover.pdf > Op 23 feb 2026, om 10:03 heeft Antony Antony <[email protected]> het > volgende geschreven: > > 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] <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]
