IETF Logo Mail Archive

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

Christoph Striecks <christoph.striecks@posteo.net> Sat, 28 February 2026 12:46 UTC

Return-Path: <christoph.striecks@posteo.net>
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 34C1FC067873 for <tls@mail2.ietf.org>; Sat, 28 Feb 2026 04:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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=pass (2048-bit key) header.d=posteo.net
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 p-DhRxYnhhDp for <tls@mail2.ietf.org>; Sat, 28 Feb 2026 04:46:08 -0800 (PST)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 B5F9FC06786C for <tls@ietf.org>; Sat, 28 Feb 2026 04:46:08 -0800 (PST)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 5DA57240027 for <tls@ietf.org>; Sat, 28 Feb 2026 13:46:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=posteo.net; s=2017; t=1772282761; bh=1skOMAu+jUZ6WEDLf/zdDgrMe/T7ATPOnmTq2cDQUPY=; h=From:Content-Type:Mime-Version:Subject:Message-Id:Date:To:From; b=ctzTMdHvTu7WniQLuCcElxL2Mu9d3RzjPAZLhllfnwJ3QiuhGvjIvQ2JYckFUBk2M TNoZKtf+KiN6AbCwQ9DEeNWhhiznirsnBA/64f3gRfGLK9Fe/481WM/sJCAHRoaBkc iLLkKJ7PFiRQbeyai5NlNA0dUTgM/jYnz1x1my67I91UGvjGV9DubMrmTOWeDVYOcp PrHoof91wZaXc3eSHmMS1CYAAsU0lWX/LvzUvmjK0gGLNN7id3i8U24QBgcDmS6ftz 7kU5AwkAnK4d3PHI4aCkYhwfRAKI9+e0WIiKJsSPwqUljlyf5p+inzyS+8ak5pWo4s xBYHvo8PqbFlA==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4fNQ0n00Tlz6txj for <tls@ietf.org>; Sat, 28 Feb 2026 13:46:00 +0100 (CET)
From: Christoph Striecks <christoph.striecks@posteo.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F2B325B2-717A-496B-9AFB-F0E1BCA16317"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.8\))
Message-Id: <3996BAFA-35D8-459B-8FD8-B1D43865E27D@posteo.net>
To: tls@ietf.org
X-MailFrom: christoph.striecks@posteo.net
X-Mailman-Rule-Hits: nonmember-moderation
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0
Message-ID-Hash: KLQ6QRLGMCAO22VQAC3D6L5GW3VH5A7N
X-Message-ID-Hash: KLQ6QRLGMCAO22VQAC3D6L5GW3VH5A7N
X-Mailman-Approved-At: Mon, 02 Mar 2026 08:50:50 -0800
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/IVWKEsnAPELcixeXT-lUi5dlWDQ>
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>
Date: Sat, 28 Feb 2026 12:47:42 -0000
X-Original-Date: Sat, 28 Feb 2026 12:46:01 +0000

Dear all,
+1 on Tibor’s thoughts below.
Best regards
Christoph
> On Fri, Feb 27, 2026, at 11:19 PM, Tibor Jager wrote:
>>>> Am 27.02.2026 um 21:16 schrieb Ilari Liusvaara <ilariliusvaara@welho.com>:
>>> - 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.
>> 
>> I think it is unwise to rely *only* on ML-KEM (or any other scheme
>> based on relatively new hardness assumptions), and currently do not
>> support any draft that does not use hybrid cryptography. In particular
>> when the use of hybrid crypto comes with negligible overhead, as for
>> ML-KEM + ECC.
>> 
>> For almost every broken cryptosystem there was a time when there seemed
>> to be no evidence that it is weak. ML-KEM still needs to stand the test
>> of time.
>> 
>> Best regards,
>> Tibor

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