IETF Logo Mail Archive

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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 27 February 2026 20:16 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 6162BBFE43D8 for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 12:16:36 -0800 (PST)
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 OXw87tehFIH9 for <tls@mail2.ietf.org>; Fri, 27 Feb 2026 12:16:35 -0800 (PST)
Received: from smtp.dnamail.fi (sender001.dnamail.fi [83.102.40.178]) (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 A8C35BFE43D3 for <tls@ietf.org>; Fri, 27 Feb 2026 12:16:35 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.dnamail.fi (Postfix) with ESMTP id D421E211304C for <tls@ietf.org>; Fri, 27 Feb 2026 22:16:34 +0200 (EET)
X-Virus-Scanned: X-Virus-Scanned: amavis at smtp.dnamail.fi
Received: from smtp.dnamail.fi ([83.102.40.178]) by localhost (dmail-psmtp01.s.dnaip.fi [127.0.0.1]) (amavis, port 10024) with ESMTP id 18iPA74uGm9x for <tls@ietf.org>; Fri, 27 Feb 2026 22:16:34 +0200 (EET)
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 E97872113E02 for <tls@ietf.org>; Fri, 27 Feb 2026 22:16:33 +0200 (EET)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.dnamail.fi E97872113E02
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=welho.com; s=2025-03; t=1772223394; bh=Q8MyPxcuHGEMlEPp68HH6gdoffguBwpY7LirWmJmMO0=; h=Date:From:To:Subject:References:In-Reply-To:From; b=RBF8hcI1ad8nsBfZuu+km7hEoVUaH05x4vgqY+Kev6ahzQUxz8Rm+4ZLQZYznbRqi OTqFovPQTWqWqeVADhtg9IkjqS3hM49tyluOnCHa4upodgu72RwyJ8XWH4/5SEmmpX gxVjKuQ1fUUbsi9+21wvrHu9VcRu3lLzEQWJE4pkJJxtlfUal0SJdUaqcV8xhmAwxN awNtwzlcTo3xuH/YQIlNekM8qk+vL+0y9r1Noc4OFi+NJ/iJAcvOt0JJHy5BKpZ/Ol fDaJzhOBwJKtjMgRAYCmvJsxWzHYG1h5qZPQZ4IDHlja2r38EcPydhftaIoK6kVRNg AynqblUckgSow==
Date: Fri, 27 Feb 2026 22:16:33 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <aaH7oSjfTR6KnmW8@LK-Perkele-VII2.locald>
References: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAOgPGoDLVqAVesWjrrD9ZR8HMkqQVLMp69vOkXPkk87MzcsOSw@mail.gmail.com>
Sender: ilariliusvaara@welho.com
Message-ID-Hash: RLGIUGGNQCWDEIS656FS2NUGBYCE4E4V
X-Message-ID-Hash: RLGIUGGNQCWDEIS656FS2NUGBYCE4E4V
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-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/2-fOKbwgEV3rFbDoJnuhNMyJA-A>
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 Thu, Feb 12, 2026 at 11:05:22AM -0800, Joseph Salowey wrote:
> This message starts the second Working Group Last Call for the pure ML-KEM
> document (draft-ietf-tls-mlkem-07).
> 
> 
> The file can be retrieved from:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
> 
> The diff with the previous WGLC draft (-05) is here:
> 
> 
> https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-07&difftype=--html
> <https://author-tools.ietf.org/iddiff?url1=draft-ietf-tls-mlkem-05&url2=draft-ietf-tls-mlkem-06&difftype=--html>
> 
> 
> The main focus of this WGLC is to review new text providing more context
> around the use of pure ML-KEM.  For those who indicated they wanted this
> text, please let us know if the new text satisfies you and if you support
> publication. This working group last call will end on February 27, 2026.

Some comments:

- The document could expand on impact of key reuse. Known impacts
  include:

  * Linking connections from the same client, which may be a privacy
    risk.
  * Making exploiting side channel attacks and implementation flaws
    much easier.

  Also, the text recommending not reusing keys could use RFC 2119
  keywords.


- Also the document could expand on applicability. Known use cases
  include:

  * ML-KEM-512: Constrained systems that nevertheless require security
    against quantum adversaries. ML-KEM-512 is among the most efficient
    quantum-resistant key exchanges known (at least among the not-too-
    exciting ones).
  * ML-KEM-1024: Protecting classified data (up to TOP SECRET level) in
    United States. ML-KEM-1024 is the only key exchange in the CNSA2
    profile.


And some notes, mainly on why I disagree with comments that this draft
should not be published:


- 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).

  This is in contrast to things like RC4, where evidence that it is
  bad did exist at the time TLS 1.0 was developed.

  Futhermore, I regard the inclusion of ML-KEM-1024 in CNSA2 as a
  serious endorsement.

  I personally think that using hybrids for encryption is worth it, but
  it is close a call, and I can see that even relatively small weight
  differences may tip the scale the other way.


- I do not think ML-DSA FO design is bad. While possibly not optimal,
  I think it is very decent. I do not think passing raw entropy is
  significant problem, as it seems to matter only with backdoored RNG,
  which is something the extra hash in Kyber can not defend against.

  In short, I think the differences between Kyber and ML-KEM are
  improvements.


- There are already 6 references on the construction, and I did try
  giving it some good blows myself, obviously that did nothing to
  stand-alone ML-KEM.


So I support publication.




-Ilari

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