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

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Tue, 07 July 2026 02:19 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 7E57E11182DB2 for <tls@mail2.ietf.org>; Mon, 6 Jul 2026 19:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1783390769; bh=7A5BBPDwOmEX+AmE6w70AW6ezl/DZFBDF1o8DNJnAN4=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=ff428LDT8X75MDAldEXhyO0Dy63DKed1lY0WScHepajhBWESYr88/iyurISxZL0Sn gj1CsD+l9zqVxj8b7bRn2famBxrsglF+gk4UIe25cktBtDoQoIfcbPymakoIeMBEOK MZBZauM+0Pfw1jqJlyPgcjW4gEuLQN599xi9y/4E=
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=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 TdSR87CELEWv for <tls@mail2.ietf.org>; Mon, 6 Jul 2026 19:19:28 -0700 (PDT)
Received: from mailout3.zih.tu-dresden.de (mailout3.zih.tu-dresden.de [141.30.67.74]) (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 6844411182D9C for <tls@ietf.org>; Mon, 6 Jul 2026 19:19:28 -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:CC:To :Subject:MIME-Version:Date:Message-ID:Sender:Reply-To: 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=JcE+dr2pTMhhwiajDT7wsY0WRv1MchSNTh1CiL/KfX0=; b=AdEdtluzTuaiVpZHT0fD/NHe7o m/gRJBUaHTr1PMGPSP2rEWXXJwy7sHpW+ifW8Xce5ydvBbHOUBHgrg9BtqGS9JhiAk3+0WZvRfwd5 8Vx39SHDGjSxHlPlYbjyAo9h8aK40G9e+lNbw0G/7bcQ/ltnUNvT5EBoWfxnolF6XpuQvMp+ritt6 5lRJe+O5+UX0CbHDK4TYk+wkJy9n8Nlj91dOqL9/F3NG0u8+b+6iW7St8ddy6q9NHGa23nIIqf87O QrinXiKw9I889F5XhgHCjllw8pX+X4FnuNTOx6Q90Fm0vjovFVbnoN4F65FxkN1L7nfcuVG8yZvld WrBh/kiw==;
Received: from msx-t422.msx.ad.zih.tu-dresden.de ([172.26.35.139] helo=msx.tu-dresden.de) by mailout3.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 1wgvPD-000qJe-0a; Tue, 07 Jul 2026 04:19:27 +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; Tue, 7 Jul 2026 04:19:24 +0200
Message-ID: <3485cbbc-fb4d-4d22-b790-c6e724ff12b0@tu-dresden.de>
Date: Tue, 07 Jul 2026 04:19:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Tanja Lange <tanja@hyperelliptic.org>
References: <akwuKgXG5Kc5wA2I@ein.win.tue.nl>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <akwuKgXG5Kc5wA2I@ein.win.tue.nl>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms010303060803020009050908"
X-ClientProxiedBy: MSX-L415.msx.ad.zih.tu-dresden.de (172.26.34.135) To msx-t422.msx.ad.zih.tu-dresden.de (172.26.35.139)
X-TUD-Virus-Scanned: mailout3.zih.tu-dresden.de
Message-ID-Hash: 5C5FCVH4P3KIXRTLKM5VAN74GMCQO2CC
X-Message-ID-Hash: 5C5FCVH4P3KIXRTLKM5VAN74GMCQO2CC
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
CC: tls@ietf.org
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/aXSKKRgg9aoR3vkCEf2PCgUQSgc>
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 Tanja,

On 07.07.26 00:37, Tanja Lange wrote:
> I do not support publishing this document.
>
>> Significant developments have occurred both within this document and in the broader TLS ecosystem to address the concerns raised in the last WGLC. Therefore, the third consensus call is warranted. We ask the working group to consider document publication in light of these recent changes:
>>
> I do not see any of my concerns addressed by the changes, nor do I see any
> acknowledgment of those concerns in the document.
Respectfully, that's not correct. The WG paid special attention to your 
/technical/ concerns and spent quite some energy in addressing those. 
See inline below.
>   For reference, see below for
> one of my emails from the previous last call.
>
> Regards
> 	Tanja
>
>
> ----- Forwarded message from Tanja Lange<tanja@hyperelliptic.org>  -----
>
> Date: Wed, 25 Feb 2026 21:04:24 +0100
> From: Tanja Lange<tanja@hyperelliptic.org>
> To: Nadim Kobeissi<nadim@symbolic.software>
> Cc: Paul Wouters<paul=40nohats.ca@dmarc.ietf.org>,tls@ietf.org
> Subject: Re: [TLS] Re: WG Last Call: draft-ietf-tls-mlkem-05 (Ends 2026-02-27)
>
> I very much dislike this definition of "participant" and the assumption that
> those who don't speak up are in agreement. [...]
I believe that's how IETF works.
> I think it is irresponsible of the WG to publish an RFC that encourages risky
> behavior. Users will take the reputation of the IETF and understand this as a
> recommendation, whether it says = N or not.

Bas worked very responsibly to set X25519MLKEM768 = Y. I responsibly 
approved his PRs. The WG responsibly agreed to our proposal.

The draft now responsibly includes promotion of hybrids.

Can you show me a concrete attack resulting from risky behavior?

>   As much as I like PQC and push for
> its adoption asap because we're too late (not my fault), I also warn about
> stability and code quality and we must acknowledge that. I love formally
> verified software like everybody else and it's the best we can do,
The WG spent quite some time in planning, discussing and executing the 
formal analysis to the extent that nobody was complaining about formal 
analysis. Thanks to Nadim, it was finally formally verified in ProVerif 
and checked by at least one FATT member. So we have done "the best" we 
could do, as you seem to be saying. Computational proofs already exist 
and the WG seemed to believe that to be sufficient.
>   but also
> that is still a research area and we are currently in a situation where code
> can be formally verified and have bugs at the same time.

That's may be the case but I don't know what we could technically do 
here other than forbidding key reuse. Maybe if you would have shared 
concrete ideas, we could have addressed it better.

>   That's not even
> addressing the mathematical stability of the problems.
I don't know what could be concretely done here.
>   Still, it's better to
> add ML-KEM than not deploying it, but please not without ECC.

FWIW, that's what RECOMMENDED = Y/N does. So I believe it was addressed.

Best regards,

-Usama


[0] https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html#section-5-1