[IPsec] Symmetric crypto guidance in RFC 8784 is misleading

Tero Kivinen <kivinen@iki.fi> Thu, 19 February 2026 17:54 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@mail2.ietf.org
Delivered-To: ipsec@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 8BEB9B9F5379 for <ipsec@mail2.ietf.org>; Thu, 19 Feb 2026 09:54:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iki.fi
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SAZj5jtDdybU for <ipsec@mail2.ietf.org>; Thu, 19 Feb 2026 09:54:28 -0800 (PST)
Received: from lahtoruutu.iki.fi (lahtoruutu.iki.fi [185.185.170.37]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id CB45DB9F5374 for <ipsec@ietf.org>; Thu, 19 Feb 2026 09:54:27 -0800 (PST)
Received: from fireball.acr.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kivinen@iki.fi) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4fH1Gd3pDYz49PyF; Thu, 19 Feb 2026 19:54:16 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1771523657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DAPXUqYqSRRWFZ0oNvp7r5SMrlX7H9Eop5dzToEIT+Q=; b=FgIDtCWfUYpfdDb/DRBWVY426s7Tfhm5cPC+pOE0immNHABwkqqKPqjBpKpyGDJHAbHqAv fEeEZtPQwRGEwPCi6ZDqkIinzRDldE/mRG3izacANdzc121TeP2yrsRzSo5VZMN49TGFFT l1x8vabbUWdoYmn4sVxjObV7DpyrBa9IuAxiVlYmDlixXMao9bZspLkZ6e7vzFqNeDOMPp NpqmASmEOywVNx319O2ZCP/kAWT2pLDwMb6eBJL9vq20UqRkYusRAFPDi7RmzbJBbFlG/R WRX2cRMDRtfK+MwwVJLViI4WhLSsnSD/G5Grks/zCjN1Ai7Olib19uMqHsHlQw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1771523657; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DAPXUqYqSRRWFZ0oNvp7r5SMrlX7H9Eop5dzToEIT+Q=; b=A/rKPQESL//3oXLctqdoQRgTC08EIIqJLR5203dkZWSrxn/+DbvfpyegiCHH6j5wMYuaHO qGaa83Q/uzhtk0FrXG1Ft+tAW1eyaX1yIT6VRAwB2M3V5+3Mjp/IW913yDSxgjUF5aYW9w eqeosCQhj5x3M5phkmsRSCx2MRqNxgb4Zzg7WMJKZqW2EIuM3hCnilQW8Ga47c+TDn+9l/ /IPlaAAGS5bNj5c3h/KgIW8emZuwLNahvVv6cCeNbjYAm7q21+yH2qa8C4tdioy0xPECJq MrOErRG2hw2vdc2UqG+q3YiZ18kiu/SIelHrS5+O3uRzDzJCqqaOjspXCB6icg==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=kivinen@iki.fi smtp.mailfrom=kivinen@iki.fi
ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1771523657; b=YIAlV7veNDSxIMSn/5XtCVFdfLFEsezHC0AyPJwEZyWpf6KgWWyQEEV5/377nTUH3zbTyH KADSNa0EM9yGS05Fbhh7GnRozqo2xJTNZzHWvf6pB0GSRRTv/Pjda+mQq2MJ/VbAjcQHst qluQrZcvDZFbVBioRMpEc8kh5JjOWihCM/hWbxDFCFsE8U3hBJckHLCctfFDqQceURCcLU fNAxpEVImuQdxUZzM6zR8dwGJETym21xtDmIekyofga8Xq44/17KCduC7T17N4e7x2seIk +QP4sJvufGE5FwSJdQKYfhcBxlPxaZVfnuX3sg3yXYKwq3G80CuSJpWjp8Q8iQ==
Received: by fireball.acr.fi (Postfix, from userid 15204) id 10E3B25C1392; Thu, 19 Feb 2026 19:54:16 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <27031.20040.9011.142848@fireball.acr.fi>
Date: Thu, 19 Feb 2026 19:54:16 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Thom Wiggers <thom@thomwiggers.nl>
In-Reply-To: <3FBB4534-E3D0-4046-9622-5911EA38A2DA@thomwiggers.nl>
References: <3FBB4534-E3D0-4046-9622-5911EA38A2DA@thomwiggers.nl>
X-Mailer: VM 8.2.0b under 26.3 (x86_64--netbsd)
X-Edit-Time: 3 min
X-Total-Time: 2 min
Message-ID-Hash: 3QXQRFZERFZLO6K4GUAKMRZO5HN4PT7D
X-Message-ID-Hash: 3QXQRFZERFZLO6K4GUAKMRZO5HN4PT7D
X-MailFrom: kivinen@iki.fi
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipsec.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: ipsec@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [IPsec] Symmetric crypto guidance in RFC 8784 is misleading
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/G-L1bbuFBtq0thWbdQpbJOKjbQE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipsec>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Owner: <mailto:ipsec-owner@ietf.org>
List-Post: <mailto:ipsec@ietf.org>
List-Subscribe: <mailto:ipsec-join@ietf.org>
List-Unsubscribe: <mailto:ipsec-leave@ietf.org>

Thom Wiggers writes:
> 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 agree. The text in RFC was the current understanding while the
document was published.

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

No need. We are already planning to update the RFC soon, mostly after
we have finished enough the post quantum algorithm work, that we can
add them to the document, so when we are doing that we can update this
section to match current understanding of the Grover's algorithm (and
include some proper references to it).
-- 
kivinen@iki.fi