IETF Logo Mail Archive

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

Tanja Lange <tanja@hyperelliptic.org> Tue, 30 June 2026 22:29 UTC

Return-Path: <tanja@hyperelliptic.org>
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 B57ED10B2E1AC for <tls@mail2.ietf.org>; Tue, 30 Jun 2026 15:29:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782858585; bh=RTaOdAnNuGrzthDXJetvirgHwI+x8MbaK6vygRyfOSA=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=oOpyWAav++Fu9RxazdRho2GjLA81sMQRpsj34rWUNVQkxOsHL/K+WQbbjb92VhXYn ww0yg/XYhrCZZvjd35mBvBNoRvS2J0PWY2l3f+4ZJjD4Y0IHJjj8Lwm3voLD+uraQe 98kTLMU2dGxJyn5a+kq9y7dA8YEbWv6GTc5O0GbI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 DkpBovde_qen for <tls@mail2.ietf.org>; Tue, 30 Jun 2026 15:29:44 -0700 (PDT)
Received: from calvin.mcs-cc.tuehosted.nl (calvin.mcs-cc.tuehosted.nl [192.87.90.60]) by mail2.ietf.org (Postfix) with SMTP id E334910B2E185 for <tls@ietf.org>; Tue, 30 Jun 2026 15:29:43 -0700 (PDT)
Received: (qmail 34415 invoked from network); 30 Jun 2026 22:29:36 -0000
Received: from hyperelliptic.org (192.87.90.62) by calvin.mcs-cc.tuehosted.nl with SMTP; 30 Jun 2026 22:29:36 -0000
Received: (qmail 721147 invoked by uid 1004); 30 Jun 2026 22:29:35 -0000
Date: Wed, 01 Jul 2026 00:29:35 +0200
From: Tanja Lange <tanja@hyperelliptic.org>
To: Soatok Dreamseeker <soatok.dhole@gmail.com>
Message-ID: <akRDT6lg-u8swZo_@ein.win.tue.nl>
References: <akQtnH-z417KPh12@lady-voodoo.lan> <0656002E-640C-4140-8A64-1547E6716707@ll.mit.edu> <CAChr6Sy=JSyN46cEYgV6azxqY9FF4gaQdQfU2S74o5W32xfSSQ@mail.gmail.com> <CAOvwWh1A7hFmLPgUftmLoNtNJ8YtQrb1616cqB32ZBdExpg_sA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAOvwWh1A7hFmLPgUftmLoNtNJ8YtQrb1616cqB32ZBdExpg_sA@mail.gmail.com>
Message-ID-Hash: 4IU4QAWFSMAOTSN63JVHQMKSIIE7G3GO
X-Message-ID-Hash: 4IU4QAWFSMAOTSN63JVHQMKSIIE7G3GO
X-MailFrom: tanja@hyperelliptic.org
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: Bertrand Jacquin <bertrand=40jacquin.bzh@dmarc.ietf.org>, "tls@ietf.org" <tls@ietf.org>, "draft-ietf-tls-mlkem@ietf.org" <draft-ietf-tls-mlkem@ietf.org>, "tls-chairs@ietf.org" <tls-chairs@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXT] 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/g2JIyULihGxzNTDhhgl1MabOnYM>
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>

You mean the competition where Rainbow got broken in February 2022, a few
months after the end-of-2021 date which NIST had announced as the planned end
of the competition? Where GeMSS had its underlying hardness assumption pulled
out under it in November 2020? Where we're having an entire extra competition
on signatures because of this? Where an IND-CCA2 issue in HQC was found after
it was selected for standardization? Not to mention all the other systems that
went down along the away, despite being seemingly based on solid assumptions.
Did you count how many of them used lattices?

Funny enough there doesn't seem to be anything wrong with the "moon math" as
far as we know, it was just the usual issue that a hard math problem got
weakened in the process of turning it into a cryptosystem, the torsion points
had always been the most likely issue, we just didn't see the right tool to
use them. Are we going to say the same about power-of-2 cyclotomics in a few
years?

In the short term I'm more concerned about implementation errors, given the
scale of the new rollout, and consider it reckless to give up on existing
protections that have gone through years of vetting and fixes. In the long run
I'm not convinced that what we'll switch to after ECC + ML-KEM is ML-KEM, it's
much more likely that by then we'll have a different system -- in the
optimistic case because we can do so much better (already now we have systems
that are smaller and/or faster and based on the same ideas as Kyber, 9 years
more of research make a difference), and in the pessimistic case because we
need to increase the parameters or even move to a different system. I don't
like the term "agility" and have complained about the misunderstandings it
creates, but any change in systems now should be done in a way to make the
next one easy.

All the best
	Tanja

On Tue, Jun 30, 2026 at 05:20:44PM -0400, Soatok Dreamseeker wrote:
> Something that has already happened to a moon math submission that was not as
> widely understood as lattices. SIKE being broken was the international
> standardization effort successfully working to motivate folks to find attacks
> against novel cryptosystems. Using it as an indictment of an unrelated
> algorithm is alarmingly ignorant.
> 
> On Tue, Jun 30, 2026 at 5:13 PM Rob Sayre <sayrer@gmail.com> wrote:
> 
>     On Tue, Jun 30, 2026 at 2:09 PM Blumenthal, Uri - 0553 - MITLL <
>     uri@ll.mit.edu> wrote:
> 
>         People seem to keep forgetting (or ignoring) the whole purpose of the
>         PQ.
> 
>         If your data won’t remain sensitive by the time CRQC arrives - you
>         don’t en need a hybrid. Just use your Classic ECC, experiment with PQ
>         or not, and prepare for eventual transition at some point in the
>         future.
> 
>         If your data will remain sensitive - then the difference between “it
>         got compromised today” and “it got compromised with CRQC” is small, and
>         ECC won’t help at all.
> 
> 
> 
>     That's not the argument, though.  It's that classical attacks might break
>     the PQ algorithms. Something that has already happened.
> 
>     thanks,
>     Rob
> 
>     _______________________________________________
>     TLS mailing list -- tls@ietf.org
>     To unsubscribe send an email to tls-leave@ietf.org
> 

> _______________________________________________
> 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