IETF Logo Mail Archive

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

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 08 July 2026 20:53 UTC

Return-Path: <ilariliusvaara@welho.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 81CB511369C84; Wed, 8 Jul 2026 13:53:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783543995; bh=JuajIS07y+WyJ7gooYo4nAJ/A2Z26/DKdJc2UO3dAsU=; h=Date:From:To:Subject:References:In-Reply-To; b=VUxxZtCVVjWSEc77joaFJQdXoAZPwA7cr4T6Za00Mkmt1+A9OWq09six0yWScJ6aB oPiKBHtr89gBGpodddeXEaksstHqhDESq6Kt4rL7TWlVtqt/mqX4+pVU9TmVXQO4fL 0gndjTcdTHRUy6rDGOCYSe/hVNUpiQ0xOSmOfh18=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=welho.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 96VYJqGF2zYV; Wed, 8 Jul 2026 13:53:12 -0700 (PDT)
Received: from smtp.dnamail.fi (sender103.dnamail.fi [83.102.40.157]) (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 EBF51113699C4; Wed, 8 Jul 2026 13:52:33 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.dnamail.fi (Postfix) with ESMTP id B87FE4098E8A; Wed, 8 Jul 2026 23:52:32 +0300 (EEST)
X-Virus-Scanned: X-Virus-Scanned: amavis at smtp.dnamail.fi
Received: from smtp.dnamail.fi ([83.102.40.157]) by localhost (dmail-psmtp02.s.dnaip.fi [127.0.0.1]) (amavis, port 10024) with ESMTP id CdD-1mkLleyM; Wed, 8 Jul 2026 23:52:32 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-117-27.bb.dnainternet.fi [87.92.117.27]) (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: hliusvaa@dnamail.internal) by smtp.dnamail.fi (Postfix) with ESMTPSA id 0FECC4098E83; Wed, 8 Jul 2026 23:52:31 +0300 (EEST)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.dnamail.fi 0FECC4098E83
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=welho.com; s=2025-03; t=1783543952; bh=MJbiORoAZ5P76O42nq3MaJrH+JPBzMkmDBVHC+tcqEQ=; h=Date:From:To:Subject:References:In-Reply-To:From; b=r8PTksAFcuDIZDrJZHDGLVVhdVJAUDVMOtRVQABI7zPeUQOogV/ge25eFB9pEUZAT dk3q4etE+QL+bGILyGF1Dyq0ZC1V7LVpJceShaVjqheFXEuPaSnR0t1MlUWiPOuKel j9YftGpKpcjnU1+ptw87YJwGLQQ+Cf+uLO8GmoMeB3Fak0kZeVnZC2gWNp6Znm/a74 ZYy7ltCkaVyCjYJedgOYMtYi8gJAo1Z3Ck0QS/AwafeIMkcn1hYFhDhXsNhrikhklq kwqYwO42XYofxSW+RlxudqHxu77luPqtGCf66VlEAcSkUlq/sIIBJrCZyrLB7JUIhH P69JWmpOL+Sng==
Date: Wed, 08 Jul 2026 23:52:27 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: draft-ietf-tls-mlkem@ietf.org, tls-chairs@ietf.org, tls@ietf.org
Message-ID: <ak64iwRObZo0YJpK@LK-Perkele-VII2.locald>
References: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <178231320760.1520243.5914961961176039994@dt-datatracker-f9b87776f-8pmmg>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: H5D7YPUJQ6PWSGR3MWYFDS4BFDV3LXTX
X-Message-ID-Hash: H5D7YPUJQ6PWSGR3MWYFDS4BFDV3LXTX
X-MailFrom: ilariliusvaara@welho.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
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/1E4wiQuKTXUEFwLf4Z6X1yozJuA>
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>

On Wed, Jun 24, 2026 at 08:00:07AM -0700, Joseph Salowey via Datatracker wrote:
> This message initiates a new Working Group Last Call for
> draft-ietf-tls-mlkem[1], which defines standalone ML-KEM key
> establishment for TLS 1.3. 

I support publishing this.


I do not think hybrids are a major improvment. However, because hybrid
key exchange in TLS 1.3 is extraordinarily cheap, I think ECDH+PQ
hybrids should be used unless following security profile standard
specifying otherwise, CRQCs having rendered traditional cryptography
moot, or system constraints somehow make hybrids impractical.

And given how close my position is, it takes very little to tilt
the scale the other way. Furthermore, CRQC appearing would instantly
tilt the scale the other way. So I think wanting to use stand-alone
ML-KEM is completely understandable.

(My position on hybrid signatures is very different due to much
bigger costs, and is not even close to the tipping point.)


ML-KEM security, mathematical level:
------------------------------------
Post-quantum cryptography is not a type of cryptography, it is attribute
of cryptography. The candidates to NISTPQC were very diverse, and as
different types of cryptography tend to have different attacks (with
some common ones), one can not use failures of other types (e.g., SIKE)
or the general failure rate (there was plenty of "snake oil") as
evidence against Kyber/ML-KEM.

For the submissions based on lattices, the issues seemed to be mostly
bad parameter choices and some other details. Which is also to be
expected, and does not reflect badly on Kyber/ML-KEM.

The MLWE problem underlying Kyber/ML-KEM seems to be the best problem
currently available. Decent message sizes combined with loads of
analysis. LWE would be even better from analysis standpoint, but the
message sizes are pretty painful.

Cryptography based on lattices is not new. NTRU is from 1996, and LWE
(which is commonly regarded as better than NTRU) is from 2005. In
addition Kyber/ML-KEM also has extensive analysis as part of NISTPQC,
probably exceeding any other candidate KEM. Lattices are also a
generally useful topic, and as such have attracted a lot of mathematical
research for a long time.

And looking at known attacks, it is clear that anything besides
breaking ML-KEM-512 with extreme effort (not going to be worth it)
requires a fundamentally new attack.

Comparing to ECC, ECC has also seem a lot of analysis since it was
introduced in 1985, and is also based on generally useful topic that
has attracted a lot of mathematical research over a long time.
Breaking the cases that have not already been broken also requires
either quantum computer or a fundamentally new attack.


ML-KEM security, implementation level:
--------------------------------------
Unlike mathematical level, which needs to stand the test of time, the
implementations do not. A well-done implementation is good right off
the gate. A badly-done implementation will remain bad even after
plenty of time.

Implementation quality is not gated by algorithm understanding or CS
theory. As consequence, implementations do not really improve over
time. More implementations get written, some of those are good. And the
bad implementations tend to patch the worst stuff (but likely never
become good).

Fortunately, implementation quality of ML-KEM in TLS is not very
important: ML-KEM is not prone to to implementation flaws so bad that
all security is destroyed, hybrid or not. The remaining flaws tend to
be either strongly mitigated by not reusing keys (required by
RFC8446bis) or destroy interop. Hybrids are practically useless here.

Comparing to ECC, ECC also has history of all kinds of bad
implementations. And some forms of ECC (thankfully not supported in
TLS 1.3) are not resistant to flaws that instantly destroy all
security.




-Ilari

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