Subject: [IPsec] Re: Symmetric crypto guidance in RFC 8784 is misleading
From: John Mattsson <[email-masked]>
To: Thom Wiggers <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 19 Feb 2026 16:05:37 +0000
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>

Please do.

That this was nonsense was clear already in 2020. Both public-key and symmetric crypto should follow the five quantum-resistance security levels defined based on symmetric crypto. In addition of taking billions of years, the qubits required for a quantum attack on AES-192 would cover the surface area of Betelgeuse...

John

From: Thom Wiggers <[email-masked]>
Date: Thursday, 19 February 2026 at 15:21
To: [email-masked] <[email-masked]>
Subject: [IPsec] Symmetric crypto guidance in RFC 8784 is misleading

Hi all,

I was going through the security considerations of RFC 8784 and I saw the following:

[…]

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.

[…]

By our now more nuanced understanding of Grover’s algorithm (in particular how expensive and poorly parallelizable it is), this recommendation is entirely no longer necessary. For example, NIST also write that using 128-bit keys is just fine.

I’m just not sure if this warrants submitting an erratum.  Should I submit one?

Cheers,

Thom