IETF Logo Mail Archive

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

Andrey Jivsov <crypto@brainhub.org> Sat, 28 February 2026 00:06 UTC

Return-Path: <brainhubr@gmail.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 59D50C00E87E for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 16:06:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.893
X-Spam-Level:
X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=0.001, 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
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 JdTrhW_AKG-r for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 16:06:07 -0800 (PST)
Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 57181C00E35D for <tls@ietf.org>; Fri, 27 Feb 2026 16:05:30 -0800 (PST)
Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-5feeddacbacso595370137.3 for <tls@ietf.org>; Fri, 27 Feb 2026 16:05:30 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1772237122; x=1772841922; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/2YKDfUxrQLmP7ZoL4d/5qgP/+YNgSDGo63SK0itQ0g=; b=wXER/q4lIu0NIK2aNZYHE0R/wVZIfES33kw94q0HoB5ilIr085FQallfBPMcZ3OhMx pozHmFBHoY6m5y6wokU/ZBy7RkCEvA1qXt0ATIoIjWqCvIvtzlwbzCth+v5gPATb0WAI m+QdjH3+6N39aVRaV9F5WCFdGOMWBOGysxl59LxWYaH72KhrT+XS5EKlfnmh8YhClSle M4Dw6RzAhLWafvfmDqzW6qMW5ueNllNvrDL8nYw9KW+qHJhjKQnOMSVzA3H9+zN5CnSk 14kF2M3KOpHGsbslMH+mKZloItM4zHVrnwPwcHADbI9Uf6z1UZhsXTK0OvyzFT1ZcjYL akHg==
X-Forwarded-Encrypted: i=1; AJvYcCWDbbhWzoSg2jUGmU95a6wWVvTx6G39z1FTpIAjonBIHydausfxo/wARX6zIvuKhtavqZ4=@ietf.org
X-Gm-Message-State: AOJu0Yz42Efh+wpd7aTi+SSJN+dlen8PSkO//DAJzeo8g7MQ7XoNXdO/ x8h6Ey10L5+BGvzIKNjicYtHkPMkWG6HY6Ak712scaVmLB2RB0z8iBJjNuiHNw==
X-Gm-Gg: ATEYQzyTaOs4EyvebTnH1hhqQRh7A0V5f2sm83vVPTOisusCi63vfSoILcP2onsivW+ QQtQZeuHtp0IJPvXLJyeOB/S6ovz5DlwBKMaMn+YcT6ACV0AV18Z5oe1K4ORYeKhJC7Z78bdIqt YlgloubzeLO3g8kzHWkXkwpejt1vb+l21SrjrH20/x43AKIa+Yfhe3+CfJN2P2tv0vWDnTSgxD2 k3+V9RzvSVjQrj6j8cw7XZybCPO0BmYP0U4DD8kL7MIaSxsbSKYEVox13UHSFeU6qAmMq93Dz7p fh10eB3f7vGtaKSIAGMJ7CUeBpUt0dZ3NH6cB7yraJlY7DIsuiqL9RgnEUJoiEGUgEfEcQGXVXD nZ5FnhxzGXqQCWFo9FuaysHFZexbGXPMPjxkn05OsOhrZ1ytWkZA9kcQ+yU0+W/dK733lBHEgUO DicZSPZPxSgYBzMAel6K/1Bv8aPqB22S87XSUmB+zzrFP9LYhKSuH3SfGSepE=
X-Received: by 2002:a05:6102:390e:b0:5fd:f509:c97 with SMTP id ada2fe7eead31-5ff323b66d0mr2085551137.18.1772237122417; Fri, 27 Feb 2026 16:05:22 -0800 (PST)
Received: from mail-ua1-f49.google.com (mail-ua1-f49.google.com. [209.85.222.49]) by smtp.gmail.com with ESMTPSA id ada2fe7eead31-5ff1e7aeb8dsm7175213137.2.2026.02.27.16.05.22 for <tls@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Feb 2026 16:05:22 -0800 (PST)
Received: by mail-ua1-f49.google.com with SMTP id a1e0cc1a2514c-94dddb3c3f0so753869241.2 for <tls@ietf.org>; Fri, 27 Feb 2026 16:05:22 -0800 (PST)
X-Forwarded-Encrypted: i=1; AJvYcCWiLDzqmeGrJLm1977GEQi31uonUcWPUYerKbT4qyeEx1WDBLMYuWSnkxS6fgUkAfoMzpg=@ietf.org
X-Received: by 2002:a05:6102:c0b:b0:5ef:a644:ca4 with SMTP id ada2fe7eead31-5ff324dad7bmr2312402137.23.1772237121793; Fri, 27 Feb 2026 16:05:21 -0800 (PST)
MIME-Version: 1.0
References: <aaH7oSjfTR6KnmW8@LK-Perkele-VII2.locald> <05529422-A5E7-4C0E-B7DF-9C6A98923035@uni-wuppertal.de> <BN0P110MB14198E08955D229A235B3EE19073A@BN0P110MB1419.NAMP110.PROD.OUTLOOK.COM> <aaIgxQtPpJfa5PFT@ubby>
In-Reply-To: <aaIgxQtPpJfa5PFT@ubby>
From: Andrey Jivsov <crypto@brainhub.org>
Date: Fri, 27 Feb 2026 16:05:11 -0800
X-Gmail-Original-Message-ID: <CAAWw3RgvxPKhCyzkexDduB5Z2zEo9sEZ=UJT22F_NQieczxCeA@mail.gmail.com>
X-Gm-Features: AaiRm50W58aSjZkHDY6V-fkE40nUKs9KZU5kZMpzwNBJqZ9nNbIgywKxpTL_pGM
Message-ID: <CAAWw3RgvxPKhCyzkexDduB5Z2zEo9sEZ=UJT22F_NQieczxCeA@mail.gmail.com>
To: Nico Williams <nico@cryptonector.com>
Content-Type: multipart/alternative; boundary="0000000000001a3974064bd71c91"
Message-ID-Hash: SXSHWCU2SPNFVWEXDIYVWLEDOKLT366I
X-Message-ID-Hash: SXSHWCU2SPNFVWEXDIYVWLEDOKLT366I
X-MailFrom: brainhubr@gmail.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: Tibor Jager <jager@uni-wuppertal.de>, "tls@ietf.org" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: [EXT] 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/5RfBXoPniNb8BCOJ4fj-ftL4Ob8>
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 agree with this summary and conclusion and I oppose the pure ML-DSA draft
as written.

Here is what I hope that the WG members can explore further.

Assume that there is only one way to do PQ KEM, which is ML-KEM + ECDH.
This approach reduces complexity of any realistic SW stack that has to have
a hybrid option.

For people who worry about cycles associated with the ECDH side, please
note the following.

(A) Reduction of options is of great benefit to anyone. Bugs are likely in
less frequently exercised code paths, and interoperability is reduced when
there are options. When everyone sticks to the only one way to do PQ KEM in
TLS, the benefits flow to everyone: analysis is easier, bugs are less
likely, handshakes are faster, etc.

(B) "I don't want to pay a penalty in cycles for ECDH". There is no
material difference in payload size, given the massive size of ML-KEM v.s.
ECDH. A client that does not want to compute ECDH can use ECC generator
point as his share. Then the other peer's share becomes the shared secret.
The same is true for the server. A peer does not need to be aware of what
the other peer is doing (but it can if it wants to replace ECC operation
with memcpy()). This is not a hybrid method when looked through the lens of
optimization described here -- this is simply an encoding (to-be-mandated)
in TLS. It's hard to argue that memcpy() transforms this method into a
hybrid mode.

So, there is only one way to do PQ KEM in TLS, and a PQ-only variant of
this can be accomplished with a simple profile describing optimization
tricks in (B). The profile can make everything fully deterministic, e.g.
mandate that each side precisely sends the generator point, making the
contribution to the handshake fully predictable, which also allows that all
ECDH "extra" can be hardcoded in pure ML-KEM implementations.

Could that work for everyone?


On Fri, Feb 27, 2026 at 2:55 PM Nico Williams <nico@cryptonector.com> wrote:

> On Fri, Feb 27, 2026 at 10:45:02PM +0000, Blumenthal, Uri - 0553 - MITLL
> wrote:
> > >> - There does not seem to be any evidence that ML-KEM is weak. I think
> > >> that if ML-KEM gets badly broken, it will be for unforeseeable reasons
> > >> (which is a risk for any cryptographic algorithm, including prime-
> > >> field ECC).
> > >
> > > Except that for a hybrid mode, both ML-KEM and ECC must be broken
> simultaneously.
> >
> > ECC break under CRQC is a-given. Which should matter for PQC context.
> > As has been repeated countless times.
>
> The fundamental disconnect is that there are:
>
>  - participants who do not believe CRQC are happening any time soon
>  - participants who do     believe CRQC are happening          soon
>    (for some value of soon)
>
> and
>
>  - participants who        worry that NSA might have a cryptanalysis of
>    ML-KEM-768 that has it have a strength of, say, 2^70ish
>  - participants who do not worry that NSA might have a cryptanalysis of
>    ML-KEM
>
> Given that, the only aproach that will please all sides is to stick to
> hybrids.
>
> But then there are participants who insist on pure PQ because of
> performance, CNSA 2.0, etc. -- not terribly good reasons.
>
> I don't know how you break this impasse, but "repeat[ing] countless
> times" is not a good answer.
>
> Cheers,
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

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