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

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Sun, 28 June 2026 15:11 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
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 E9DF810939249 for <tls@mail2.ietf.org>; Sun, 28 Jun 2026 08:11:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1782659472; bh=0wzJEqg/c90HxbJzAf/5yIq2meXr5xPhLn52i8TJPa8=; h=Date:Subject:To:References:From:In-Reply-To; b=CYxll6BNW/xdLqcrFyCZ1jRNnWZ6ISYkvuRHrgZeKp08/4tytyzM6FSoh2mya6Uus q7+GAUbZ7a4e9ktMbDVE48IDTORRk7ADKkKhyHQIubJ2QGwocycoMMTdku+M+IdmSx MbBe7MMMUc1H+Uh69/AN+lOllR5+Q2I2VJHy+Krc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.398
X-Spam-Level:
X-Spam-Status: No, score=-4.398 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_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=tu-dresden.de
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 5NqO5Alq5_sO for <tls@mail2.ietf.org>; Sun, 28 Jun 2026 08:11:11 -0700 (PDT)
Received: from mailout4.zih.tu-dresden.de (mailout4.zih.tu-dresden.de [141.30.67.75]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id C54B210939132 for <tls@ietf.org>; Sun, 28 Jun 2026 08:10:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tu-dresden.de; s=dkim2022; h=Content-Type:In-Reply-To:From:References:To: Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=HO7n9xr8N/tDPK3E0gH+e6gnPvEBL/KzyJDRC68BGz4=; b=dqMwX/Bw0zUiR9MFaAPapG5BNy FcmgaqHcRrwD6xtvCMY1E9rORnMtkElE7EFp3xcJKgzZgEofT8sOHgMpm1zPEtn4lPl0lkFaKt66H 0ItxoJRTxfxDXK3UvCYTEXGWkQbKJOF7Hxagyx0RbCmW5T17/4wkz70t9Xjrf9Ooj57JSbXKFQL99 dJHr0w+yF212DXPBA06qP5IZZXLgJet/6l4Rj8t9o3v0e5wEoOj74PLKrnLiAilIRuJWXd7VC2RXs m3N9hRsPi4LrdVAR7/VoO7jgufBoX53F/a21fYXcW7k3xGSgXr9jlpc4RgUocfLyzs7A+CIdCBwku tI5jk4Eg==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout4.zih.tu-dresden.de with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1wdr9S-002ywl-3B for tls@ietf.org; Sun, 28 Jun 2026 17:10:31 +0200
Received: from [10.12.5.228] (141.76.13.165) by msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.2562.43; Sun, 28 Jun 2026 17:10:29 +0200
Message-ID: <c75f6d14-57d3-49db-8e86-0232904dd0f5@tu-dresden.de>
Date: Sun, 28 Jun 2026 17:10:22 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: tls@ietf.org
References: <20260628130108.4149054.qmail@cr.yp.to>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <20260628130108.4149054.qmail@cr.yp.to>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms020002080206080709070104"
X-ClientProxiedBy: MSX-L422.msx.ad.zih.tu-dresden.de (172.26.34.142) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout4.zih.tu-dresden.de
Message-ID-Hash: HYQD3W6RKD4Z3KBFXCW57LWYBTGGDYMJ
X-Message-ID-Hash: HYQD3W6RKD4Z3KBFXCW57LWYBTGGDYMJ
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
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/ujw6khaeWrkQPG7UvZ-Rwj6SzrI>
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>

Hi D. J. Bernstein,

Not a process person, so won't comment on those. Respectfully and 
humbly, a few technical corrections:

On 28.06.26 15:01, D. J. Bernstein wrote:
> The TLS WG chairs write:
>> Significant developments have occurred both within this document and
>> in the broader TLS ecosystem to address the concerns raised in the
>> last WGLC.
> False.

If you believe Nadim's formal analysis in ProVerif is not a significant 
development, I sincerely encourage you to find a security flaw in the 
formal analysis. Several WG participants -- including at least one FATT 
member -- have independently reviewed the formal analysis and the paper 
and concluded that it is a reasonable model.

>> Therefore, the third consensus call is warranted.
> No, it is not. It is an abuse of power by the chairs, inflicting costs
> upon opponents to object again and again.
I respectfully disagree. IMHO, we need to know if there is something 
technical left to do on it or otherwise to stop wasting further time on 
this draft. I believe the call is well-justified.
>> - Key Share Reuse Prohibited in draft-ietf-tls-rfc8446bis: The WG
>> recently reached consensus to explicitly prohibit key share reuse
>> across connections in TLS 1.3. The new text changes the guidance from
>> SHOULD NOT to a strict MUST NOT. This resolves the concerns regarding
>> static key reuse and its associated privacy and forward-secrecy risks
>> for ML-KEM.
> It has always been clear that this matters for one person. John Mattsson
> during the adoption call wrote "I support adoption as long as reuse of
> ephemeral keys is normatively forbidden, i.e. MUST NOT reuse"; he has
> made similar comments afterwards.

Respectfully, that's not correct. John is surely not the only one. Key 
reuse was one of my *major* concerns. In fact, I had this concern even 
when I was not into the PQ. I raised this concern in the 2nd WGLC of 
this document too.

Anyway, the consensus call on this matter has confirmed that there was 
full WG consensus. I do not recall a single person objecting to that 
consensus call. This is an undeniable attestation that it was not only 
John and me.

>> - Nadim updated the ProVerif model of TLS 1.3 to evaluate KEM and
>> hybrid KEM groups in TLS 1.3. This supports other results which show
>> that KEMs are secure when used in TLS 1.3 and that hybrid groups are
>> secure even if one of the components is compromised.
> My understanding is that such formal analysis moved Muhammad Usama
> Sardar from opposition to neutral. But, again, the majority of people
> stating objections have done so on more fundamental grounds than this.

Respectfully, I believe that's wrong too. AFAIU, most of the 25 
objecters from the last WGLC now seem to be satisfied with the formal 
proof. I've seen only 4-5 of those still objecting. All other objecters 
so far are new and I haven't seen any new arguments yet. Moreover, many 
more people are now in support because of formal assurance.

The formal analysis showed both proponents and opponents were correct:

  * proponents in the sense that there is no security issue in the
    integration of ML-KEM in TLS
  * opponents in the sense that hybrids enjoy two-factor security
    properties and it is not only "proponents of hybrids" as the draft
    previously said, rather a scientifically proven fact.

I hope we can use the FATT process for controversial drafts right from 
the beginning to optimize the WG energy and avoid tabletop discussions. 
I also hope we can work like a collaborative working group rather than a 
battlefield.

Best,

-Usama