IETF Logo Mail Archive

[Last-Call] Re: [TLS] Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Thu, 04 June 2026 03:27 UTC

Return-Path: <muhammad_usama.sardar@tu-dresden.de>
X-Original-To: last-call@mail2.ietf.org
Delivered-To: last-call@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 1F2D6FA84BE6 for <last-call@mail2.ietf.org>; Wed, 3 Jun 2026 20:27:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780543635; bh=PuWgj3a4QAEYiQrwlmZx6vx3P2775rNAg8kJ5FBB3UY=; h=Date:Subject:To:References:From:In-Reply-To; b=YCbjjtmfJfFI39WcoJYwiuk18iVSzpfNqbNy51U6G2OMZ8YaS0R+ABhaHD3O+Zh1L 1r3d6Le+3o13Dp2bCrNDSaeYvVnejDVLtlB7PC9rKQwzqsgGToT2KH+YcIWN1NOLyb wzK4M5C779Vv1GHNOgbSF7RdrLn0JCZJ5aDZYv2E=
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 5ICGAQH0bSnV for <last-call@mail2.ietf.org>; Wed, 3 Jun 2026 20:27:14 -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 82457FA84AAF for <last-call@ietf.org>; Wed, 3 Jun 2026 20:26:21 -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=KjHpKKyW4KemY7yFzKUhSEVXbf+CDB5NY6qFOzx1zfU=; b=iQLTD4T2y5frLwoGeNhHVbeLvZ VtB01Y09+BlRQ0+QTKeMFIouKknT3RZ29AkPNc5z3IvodpzKfTYjJspCaoS1y+veqHvuASICwPDqC SfqW9wq8jxcbnkSa9JPXoDrStNg1PQvcQ6pfsyouY5BrO3UQIrHDm9NQ9khWC51yaCzWRSUh4wijP bt+6KXx4AVW+npMEjPDv9aKaImDfqy9yG3BWXm/44WFazOA+tudZpHTmgtZx8HPHlSe+vbs2FPo8e Jx82erGJuyA4VXDKflZLDn8Yatm5AVmxid8UkVZMkJx2xElCaQkKrX5Y11YcebkX1tSWtvH8kKRW1 JTKFlpbA==;
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 1wUyiq-004jxd-0v; Thu, 04 Jun 2026 05:26:20 +0200
Received: from [172.16.0.202] (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; Thu, 4 Jun 2026 05:26:10 +0200
Message-ID: <b40184d8-fc60-4aca-b80e-18d40fb7c2d4@tu-dresden.de>
Date: Thu, 04 Jun 2026 05:26:09 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: "D. J. Bernstein" <djb@cr.yp.to>, last-call@ietf.org
References: <20260603121536.2334600.qmail@cr.yp.to> <740B69BC-BB0D-427C-8A5A-BF5E6FEEC061@symbolic.software>
Content-Language: en-US
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <740B69BC-BB0D-427C-8A5A-BF5E6FEEC061@symbolic.software>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms000309030004040009080503"
X-ClientProxiedBy: MSX-T416.msx.ad.zih.tu-dresden.de (172.26.35.136) 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: LKJSXYYUGANGX4O6UHHVHZ7AKV6MQGU4
X-Message-ID-Hash: LKJSXYYUGANGX4O6UHHVHZ7AKV6MQGU4
X-MailFrom: muhammad_usama.sardar@tu-dresden.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; 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: [Last-Call] Re: [TLS] Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC
List-Id: IETF Last Calls <last-call.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/9xOUATVB8YIpEB8mfBNwGDjpqPo>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Owner: <mailto:last-call-owner@ietf.org>
List-Post: <mailto:last-call@ietf.org>
List-Subscribe: <mailto:last-call-join@ietf.org>
List-Unsubscribe: <mailto:last-call-leave@ietf.org>

Hi,

> I think everyone agrees that we will see severe vulnerabilities in 
> *all* software.
I don't think it has to be necessarily /severe/ in /all/ software.


# *Para 2 of [0]*

Respectfully, some of your claims in this para seem a tiny bit 
exaggerated, too. I believe no amount of code review, testing, formal 
analysis of specs, formal verification of implementation, following 
BCPs, etc. can lead to a guarantee of /bug-free/ code. Software is 
getting so complex that all of these may likely still miss some bugs.

The example I am going to give is unrelated to ML-DSA but very much 
illustrates the point I am making. Not too long ago, some folks in the 
Confidential Computing Consortium claimed that they have developed /the 
most secure/ implementation of attested TLS, and openly challenged us to 
find an issue in their implementation or show a better implementation 
than theirs. I, Slava, and Jean-Marie accepted the challenge. Doing the 
formal analysis revealed that their implementation was actually 
critically flawed and led to a /high/-severity CVE of score 7.8 (cf. 
public acknowledgment [1], security advisory [2], and published CVE 
[3]). We collaborated with them to move their implementation to a much 
more secure design. I would not at all claim it to be bug-free code.

In another case, a project claimed that they had achieved "below-zero 
trust" and we found the reality to be quite different but that's a story 
for some other day, because the mitigation is not yet in place.

# *Para 6 of [0]*

Confidentiality /and/ integrity of /what/? and /how/? Could you please 
explain the concrete attack trace in simple words?

# *Gentle reminder for outstanding objection to EUF-CMA*

Unless I missed something, I haven't seen an answer to my question in [4].

Also, John has kindly provided substantial technical response with 
concrete references in [5], to which I haven't seen a reply. Did I miss 
something?

===


> Bear in mind the following email:
>
> https://mailarchive.ietf.org/arch/msg/tls/AK7QUiiGX3ynsOhXeUuwn_IY7ik/
Thanks. John's arguments seem reasonable to me. I have tried to 
summarize them in [6].


Best regards,

-Usama


[0] 
https://mailarchive.ietf.org/arch/msg/last-call/S8CgtiIUhfswiy44IPShlePypuc/

[1] 
https://web.archive.org/web/20260227160554/https://www.ultraviolet.rs/blog/tee-tls-privacy/

[2] 
https://github.com/ultravioletrs/cocos/security/advisories/GHSA-vfgg-mvxx-mgg7

[3] https://www.cve.org/CVERecord?id=CVE-2026-33697

[4] 
https://mailarchive.ietf.org/arch/msg/last-call/MY0_F_2oANES0gmKyCjsyUn55No/

[5] 
https://mailarchive.ietf.org/arch/msg/last-call/C9b21fNHsMqgif5Tj3hWHwb62kc/

[6] 
https://muhammad-usama-sardar.github.io/risks-of-mlkem/draft-usama-tls-risks-of-mlkem.html#section-6.3-5

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