IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)

"D. J. Bernstein" <djb@cr.yp.to> Thu, 19 February 2026 21:33 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@mail2.ietf.org
Delivered-To: tls@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 4ACDFBA129EB for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 13:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
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 3FU6USZ-2hiN for <tls@mail2.ietf.org>; Thu, 19 Feb 2026 13:33:27 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 18732BA129E2 for <tls@ietf.org>; Thu, 19 Feb 2026 13:33:27 -0800 (PST)
Received: (qmail 1778416 invoked by uid 1010); 19 Feb 2026 21:33:19 -0000
Received: from unknown (unknown) by unknown with QMTP; 19 Feb 2026 21:33:19 -0000
Received: (qmail 1211664 invoked by uid 1000); 19 Feb 2026 21:33:06 -0000
Date: Thu, 19 Feb 2026 21:33:06 -0000
Message-ID: <20260219213306.1211662.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org
Mail-Followup-To: tls@ietf.org
In-Reply-To: <CAEEbLAaMEFYAe-w+G0PSpzub3JD3P0mJiuZGfhkzFDUFd3ufWQ@mail.gmail.com>
Message-ID-Hash: AXBZ4NEJQCAV6HMCP3F4K25P7TA76RKB
X-Message-ID-Hash: AXBZ4NEJQCAV6HMCP3F4K25P7TA76RKB
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Sms0nHOa2oCEI-cx0kqQJaSEe5M>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

Sophie Schmieg writes:
> [1] https://keymaterial.net/2025/11/27/ml-kem-mythbusting/

I see that you're arguing that the ML-KEM spec is too rigid to allow a
Dual EC-style secretly keyed backdoor, i.e.., that the entropy needed
for the backdoor key wouldn't be able to fit into the spec.

Was someone arguing the opposite? You write "the concerns about it are
overblown"; can you please quote the concerns that you're disputing?

I've noticed other cryptosystems that don't seem to have many knobs to
play with in the spec. For example, the starting SIKE curve was chosen
to be very concise, to remove any concern about a backdoored choice of
curve. And yet a few cryptographers, including me, were on record by
2021 stating concerns about SIKE having not been studied enough. Would
you describe the apparent rigidity of SIKE as evidence that our concerns
were overblown and that SIKE is secure? If not, why not? How exactly is
this different from what you're now arguing about ML-KEM?

RSA-512 is a well-known cryptosystem that has been applied to large
quantities of user data. The specification of RSA-512 seems reasonably
rigid. Would you describe this rigidity as evidence that RSA-512 is
secure and that concerns about RSA-512's security are overblown? If not,
why not?

FrodoKEM, which is widely portrayed as the most conservative lattice
system, says in

    https://web.archive.org/web/20230224071445/https://frodokem.org/files/FrodoKEM-sp
ecification-20210604.pdf

that it's an "instantiation and implementation" of a 2010 paper:

    https://web.archive.org/web/20111206143256/https://eprint.iacr.org/2010/613.pdf

That paper proposes a lattice-based cryptosystem, and concretely
proposes using lattice dimension 256 for security "about" 2^150 and "at
least" 2^128. This is another concisely defined cryptosystem with very
few obvious knobs to turn. Would you describe this rigidity as evidence
that this dimension-256 lattice-based cryptosystem is secure and that
concerns about its security are overblown? If not, why not?

---D. J. Bernstein


===== NOTICES =====

This document may not be modified, and derivative works of it may not be
created, and it may not be published except as an Internet-Draft. (That
sentence is the official language from IETF's "Legend Instructions" for
the situation that "the Contributor does not wish to allow modifications
nor to allow publication as an RFC". I'm fine with redistribution of
copies of this document; the issue is with modification. Legend language
also appears in, e.g., RFC 5831. For further background on the relevant
IETF rules, see https://cr.yp.to/2025/20251024-rules.pdf.)

v2.39.1 | Report a Bug | By Email | System Status