[TLS] Re: Working Group Last Call for Use of ML-DSA in TLS 1.3

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Tue, 14 April 2026 01:46 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 B15F7DBB2223 for <tls@mail2.ietf.org>; Mon, 13 Apr 2026 18:46:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776131203; bh=KjFYxUyYaSdf03jdFUZd29TfpnbVK2ONPMUfvRprpyk=; h=Date:From:Subject:To:CC:References:In-Reply-To; b=G/ENbRCH4ssTwgmy6EY7i4FRvDjluIf/S80dbF1HQjEQukIuHcxnWNcFKvwSI6TGu 9myq4XcyjZ3sSExmE1hyHMqKUvXz2Y2ERZp6iMud1k/JGtj8mzlcwDov6gfylSZuRF yHTVfg9b+ffu2cZHd31g9lmpLU8D8U4gOz4CGwFU=
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, 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_HELO_NONE=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 Se1t5az2W9BS for <tls@mail2.ietf.org>; Mon, 13 Apr 2026 18:46:42 -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 CB1D3DBB221B for <tls@ietf.org>; Mon, 13 Apr 2026 18:46:42 -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:References:CC:To: Subject:From: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=KjFYxUyYaSdf03jdFUZd29TfpnbVK2ONPMUfvRprpyk=; b=co1+Kg6s7kBtzK6q84HGyhdgrX JGDfro+DudIwq1owuIzHbpE8dKpGFw1exv0EQPCwHlltAY9JT2BMc1Hd03gCP0x5XHZ6M5QuheUY5 BfQ0BXpp/zHuaY/NXYOQf4cZHxLgmTbAPaEtaBCIzZrXud78lncGuzTf1zxxZ2wbV96Qk2zH3NQQD do+AWy5isVjuZlTQ5fiMuAG9CihzGkvjGV2fq1NYZgXeajkDUcolP9UhO9CzPsAOaTTBhGwt1sR14 3QwBzAtsB4YmQwfYhY12lhHg0NzgF5j+DcC0Uv2kKCnSbXiHPTmyZc46KJNzpYEkKEsC2Ke69H13e /i1J9j9g==;
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.94.2) (envelope-from <muhammad_usama.sardar@tu-dresden.de>) id 1wCSrQ-00DLEO-Jx; Tue, 14 Apr 2026 03:46:42 +0200
Received: from [10.12.5.228] (141.76.13.149) 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.37; Tue, 14 Apr 2026 03:46:24 +0200
Message-ID: <4ee31d51-6480-49e4-bd63-868ae6bced9b@tu-dresden.de>
Date: Tue, 14 Apr 2026 03:46:23 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
To: David Adrian <davadria@umich.edu>
References: <16CF0FDA-7263-461A-9F2B-D37DBEAF5DD9@sn3rd.com> <25c8d414-e4c8-455b-bd64-28132615ba75@cs.tcd.ie> <68f49a81-dd2c-4bea-896a-87da3e6aff68@tu-dresden.de> <CAMjbhoWwvfkfScpbf4-5PBzk__qb+6M4ZzAOba64kk9aXBba5g@mail.gmail.com> <d47a34ab-7fb9-4687-84aa-a5fa6bcf6a6c@tu-dresden.de> <2971d01a-89e3-43d3-a01d-b9c17b178763@amongbytes.com> <692bb582-ab7e-4d6b-aa75-ac5d93228bb2@tu-dresden.de> <DS4PPFA08475C7DBE27468E40C672197481C1242@DS4PPFA08475C7D.namprd11.prod.outlook.com> <LV0PR21MB6623B48B1F3A05D745F5A79D8C242@LV0PR21MB6623.namprd21.prod.outlook.com> <ad0svakv_WUM3btz@chardros.imrryr.org> <CAF8qwaBU_YHWX2MsWeeaOJ8sutR1wMozvbiTJF5kyvTE8YjWWA@mail.gmail.com> <CACsn0c=GDta824UF7uJ3nw_4U_rT=XhYOGHRemMWa+2AdbsiAg@mail.gmail.com> <3a16c7c4-345e-48ce-af70-a3bf503c8caf@app.fastmail.com> <CACf5n7_0hdeHJXXucva9pb=+pjhcgveHRpjA8XAcXB3LsYUvaw@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CACf5n7_0hdeHJXXucva9pb=+pjhcgveHRpjA8XAcXB3LsYUvaw@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms080000080807010605060202"
X-ClientProxiedBy: MSX-T415.msx.ad.zih.tu-dresden.de (172.26.35.135) 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: 4MUYRO2ZYETCAVWAQEN2IAYZLWT6LSBN
X-Message-ID-Hash: 4MUYRO2ZYETCAVWAQEN2IAYZLWT6LSBN
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: Working Group Last Call for Use of ML-DSA in TLS 1.3
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/SBe1qZ5bKnvKuDa3Pl3un9ykcTw>
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>

Folks from Microsoft would like to implement it [0].

So FWIW, I don't think some "no implementation plans" shared on list 
should reject my attestation and request to expedite adoption call. If 
someone has substantial technical concerns on the draft, it would be 
helpful to articulate those, so that I can work with authors to fix 
those. Thank you!

On 14.04.26 01:02, David Adrian wrote:
> I am perfectly fine defining composite certificates however, I will go 
> further than other David and say that Chrome cannot, should not, must 
> not, and will not implement composite certificates in TLS.

Could you please explain the rationale? Like, is it about security or 
something else? Thank you!

Best,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/tls/eoeUL_BoClXPyro2AEe7zNwuiJo/