IETF Logo Mail Archive

[TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)

mark@schultz-wu.com Wed, 01 July 2026 21:12 UTC

Return-Path: <mark@schultz-wu.com>
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 F41A110BF03CF for <tls@mail2.ietf.org>; Wed, 1 Jul 2026 14:12:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782940321; bh=vd+2pmyGOQwGlC9mvbdGGtYgamwhEDVdlA9OJP9c9C8=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=zaFEIQdbgfRkuTvMHwCCGMKfee1NnJgquj+CQr2STCxg9OYqyiLqSqmbNsuOFsUXu CkmtcugvwIr2r7EphnhRMbew/bzOu1il0snBVo9DsWH3ZGn5HqL1E1E5xENarKnEu7 N3Cpqtac9hvdhrZ4mYTHiMnQya8DPhlccxmRqscI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Level:
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=schultz-wu.com
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 wkdfpaYDZUsI for <tls@mail2.ietf.org>; Wed, 1 Jul 2026 14:12:00 -0700 (PDT)
Received: from outbound.mr.icloud.com (mr-2005h-snip4-2.eps.apple.com [57.103.71.75]) (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 E8CA710BECDBC for <tls@ietf.org>; Wed, 1 Jul 2026 14:03:34 -0700 (PDT)
Received: from outbound.mr.icloud.com (unknown [127.0.0.2]) by p00-icloudmta-asmtp-us-west-2a-60-percent-0 (Postfix) with ESMTPS id 564ED1800715; Wed, 01 Jul 2026 16:29:05 +0000 (UTC)
X-ICL-RepId: 019f1e83-3d99-7494-81da-90a3418e835c
X-ICL-Out-Info: HUtFAUMHWwJACUgBTUQeDx5WFlZNRAJCTQhIB0MGUwpeCE8DQwZaA1BcHA4AVhlZMEobWxhbH0hdTg0dDlgGEhZdRUAOXx5eBENVRBgZCF0dGQpQUAVLWhVVFw4CQh9QH0wWV0NaGRwZWhRcGFNFUR9UWEMZRVZpQQtPHV0ZWxxCZFhXCQoYURhMFEcXGhxHXloXXk1aAlZNBTsDKXYuCkALVQFcci0fRAFOAEB1LwRGFE8KWQBddkMPSQIpAStBE1ENXxlNRkUFFxtcAAlLRglJHQ4OQhhGH1QnVwJaClse
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=schultz-wu.com; s=sig1; t=1782923345; x=1785515345; bh=vd+2pmyGOQwGlC9mvbdGGtYgamwhEDVdlA9OJP9c9C8=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To:x-icloud-hme; b=hRoauXlW1o6LJZ/X1Kj20A1vG3r/CwatbgX7/Jva9bwbOoAMjjXZCJZHT66i+uSyIaIeh2yLh8QhDFioN6DuG6GdZxsg1EK+0Jhr6Ev7N9oA4g/ABsczyjh95ACfdVhd4ygWeiegUhKVpr+sz91bTDM+DrMpxbnNApR3k4cPyrF95z3XGIGe0fJw0HOcSjg9vxoiQ/E2QRpBklCM1hE8L13btxDWykiBtHW6otXDgZGp2DmAm5NRhiCtZtDKE6E7UZ0qbMNMev+PY161E5DQjIrb68n2dn07gHZZok/hgWqCAbuHK4D4bOBUu5wwIqLr9qj6Y/5ZwFfiHNQ4ZWmHfw==
mail-alias-created-date: 1725820296137
Received: from smtpclient.apple (unknown [17.57.152.38]) by p00-icloudmta-asmtp-us-west-2a-60-percent-0 (Postfix) with ESMTPSA id 94DDB1804EEC; Wed, 01 Jul 2026 16:27:32 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.600.51.1.1\))
From: mark@schultz-wu.com
In-Reply-To: <492f2df5-0e44-4140-8d72-9046a5a8e3b5@zhaw.ch>
Date: Wed, 01 Jul 2026 11:27:25 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0DAE802-21EF-4863-BD66-79476D3611D6@schultz-wu.com>
References: <492f2df5-0e44-4140-8d72-9046a5a8e3b5@zhaw.ch>
To: Stephan Neuhaus <neut@zhaw.ch>
X-Mailer: Apple Mail (2.3864.600.51.1.1)
X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNzAxMDE3NSBTYWx0ZWRfX5fEyBA0iwoyp 0/2z8c6VkSLnbs8kdRpKKAXuAKlmOcJaZYW2d1BM1Ym+47IjfOvPKGwks4aOJIbhjJPYmP+JRGw XkXJW2Zf0yxUCL40SqIK0TWX4by+JTucB1P3Y8WtbsPrWHMkqTclFfy2vgZigDYSHRUf3g3oz3N YCTEN4zjcuNdMS2QJpjLeW21CCXto5BkMzbLgtq3BUKmahE5KQOlHAkR9Q3Tqpk51T2apu3jbTS BGyE2ESjxMRL+j+hgltclt5HQBWDWrP3tbD4wiHuus8KZQS6+z6XVErVQPH9Ek3Q2rbh8+tixG1 R0odCxyml9Z1iRbcwaV
X-Proofpoint-GUID: BbYPEk67ARg7SFqcp6VQ_ouKVa7INswD
X-Proofpoint-ORIG-GUID: BbYPEk67ARg7SFqcp6VQ_ouKVa7INswD
Message-ID-Hash: TFBLJMNCZ4T22BTZMNKLHVWVFIAEATRG
X-Message-ID-Hash: TFBLJMNCZ4T22BTZMNKLHVWVFIAEATRG
X-MailFrom: mark@schultz-wu.com
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
CC: tls@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-08 (Ends 2026-07-08)
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/HznE1IcCjstEjhh4M1p59qX1JlQ>
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>

I support publication of this document, and am replying to this particular message to clear up significant misconceptions I’ve seen (both here and elsewhere).

Unfortunately, it appears that there are very few people on this mailing list familiar with lattice-based cryptography (there are more who are familiar with ML-KEM, but if the deluge of recent emails is anything to go by, there are not nearly enough who fall into that camp either…). I myself am a lattice-based cryptographer, though one who works on Fully Homomorphic Encryption mainly. So more on the theoretical side (and with hardness assumptions even less solid than those of ML-KEM).

So let’s first talk a brief history of the field

1. The initial (post-hoc defined this way) lattice-based scheme was due to Merkle and Hellman, namely their “knapsack” cryptosystem in 78. This was broken by Shamir in 84. I call this a post-hoc lattice-based scheme as it heavily inspired later work in the field (Micciancio’s early 2000s papers often mentioned knapsacks built from cyclic lattices etc).

2. in the 90s, further (post-hoc defined this way) lattice-based schemes were defined. Of them, only NTRUcrypt is still plausibly fine. Lattice-based systems had significant issues, in particular there were no secure lattice-based signatures.

3. In 2005, Regev introduced LWE, and defined a simple (e.g. IND-CPA) encryption scheme based on it. It has had no real issues for >= 20 years.

4. Algebraic structure in lattices dates back to NTRU in the ~90s. Outside of NTRU, it first appeared in ~2001 in what we would now call the R-SIS problem, due to Micciancio. This was broken (due to using cyclic lattices)

5. Algebraically structured lattices using quotients by power of two cyclotomic polynomials (“negacyclic lattices”) have been used since ~2009 I think. RLWE and RSIS have had no significant issues since then. The only “real” issues are
5a. the attacks on the sPIP problem over these lattices. This is a different problem. We would not want to use schemes that use this problem.
5b. There are better quantum attacks, not against RLWE, but against other “rank one” lattice problems. See the line of work starting with Biasse and Song, 2016. out of an abundance of caution (and for parameter flexibility reasons) this encouraged people to use rank > 1 lattices. Those better quantum attacks have not been generalized to impact any “standard” lattice problems (RLWE or MLWE over power of two cyclotomics) in the ~10 years since that paper came out.

This is to say that all of the “exciting breaks” of lattice-based cryptosystems people fear with a new form of cryptography HAVE happened. Most happened in the previous millennium though. SOTA attacks against LWE (and its algebraically structured variants) have been “stable” in the sense that they take 2^{cn} time for a constant c (and have exponential memory costs as well iirc) for close to 2 decades. Over time the constant c has mildly decreased, but it has now been stable for nearly a decade.

None of the above is controversial at all. Any lattice-based cryptographer could tell you the same story. They mostly don’t bother because dealing with Bernstein’s attempts to obfuscate the above (very clear) story is exhausting. We can already see this in this mailing list, where many people have responded to Bernstein’s call to interrupt this process despite knowing very little about the field.

Concerns about implementation quality are valid. Even here, lattice-based schemes are much easier to implement than RSA/ECC schemes. It’s mostly arithmetic of word-sized modular integers. This doesn’t mean everything is trivial, but it does make the huge amounts of concern claimed by non-experts quite puzzling. I’ve seen some people point towards the “glue code” to create the hybrid as being plausibly its own source of implementation issues. Any code has possible implementation issues. Perhaps that means no new cryptographic code should be written, and we should dissolve this working group. Or, maybe we deal with that as best as we can.

Best,

Mark


> On Jul 1, 2026, at 5:32 AM, Stephan Neuhaus <neut@zhaw.ch> wrote:
> 
> I do not support the publication of this document.
> 
> I remember well that security standards get broken: when they have been well-reviewed, but especially when they're new. Bugs show up in the math, but also in implementations. Lattice cryptography seems to me to be a very active field of research, when quite fundamental results (and bugs!) are still being discovered, both in the math and in the implementations. From a risk-management perspective alone, I believe that it's too risky to standardise, even as "informational", a mode of encryption that relies only on these new methods.
> 
> Cheers
> 
> Stephan
> 
> PS: Full disclosure: I have just joined the TLS mailing list, mainly to say just this. I also have no standing in the cryptographic community, except that I have published a paper last year together with Peter Gutmann of this parish, about how all of the published quantum factorisation records are bogus [1]. What kind of standing this gives me, if any, is anybody's guess.
> 
> [1] https://eprint.iacr.org/2025/1237
> 
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org

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