[TLS] Fwd: New Version Notification for draft-usama-tls-risks-of-mlkem-01.txt

Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de> Fri, 29 May 2026 10:35 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 DEC22F74F8CF for <tls@mail2.ietf.org>; Fri, 29 May 2026 03:35:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780050903; bh=27SWeUXx93swyIrZjB1IE/oB4/F7fBZx+3I9QvpaSN0=; h=Date:Subject:References:To:From:In-Reply-To; b=oN5YBpk9gylWEnIohxGyKRtQawap9voDPZdh1RkHiS4HCmqIrd2+BD5NLPhM/clLY 6EnKjvfo6ZdD1ohDE9gIlc/yM4ZktGf18n98e8r2QeJQp6nPphM95kDgQe/m4XFfb4 lv+FQinLhK29/6aIsFDA6opNV6xb3uOYLyKlhMis=
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 jj4hqPC9SVBh for <tls@mail2.ietf.org>; Fri, 29 May 2026 03:35:02 -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 3654DF74F52A for <tls@ietf.org>; Fri, 29 May 2026 03:31:36 -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:To:References: 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=MWJpYQsJ5YiTG6pKZjrPle9fTWw8tFfV1ECEIDMAOvg=; b=Yyns40x9ID7kOpldMpr1A3oMs7 +ESZjFR7ocUIKftm03C48/GwoWfZpMoc2MpFuoPd/i2s/nCG+zvWzP/NxTStNRLsn5EDJmlkdKATY gh8ScaIVW+aVNVCNYg/IdzrozBekKB0Dl7wZtkF6I3DWxQrK5pJZhE75GWpsQAUJDetrREcKpdbvt Fu4OFcuWo/gXcJ9T1GvYWqbpaFehMb04/52Gb7Bxmx0xQKiMBlYc3Gu21qQZr4WmJ06b43OO5qgjs 6f9bHTmtwjDjZd3BOKtfXZqNclNr5qABSAfV4oLajqUlU6EfgRyp/Mi/1llsrimwg48hkokiZSujl PCUMoARg==;
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 1wSuV4-000WPH-27 for tls@ietf.org; Fri, 29 May 2026 12:31:35 +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.37; Fri, 29 May 2026 12:31:26 +0200
Message-ID: <b9a8212d-cfe0-402b-9a8a-f63c1712d1db@tu-dresden.de>
Date: Fri, 29 May 2026 12:31:25 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
References: <178004897406.1571084.15428249207754239073@dt-datatracker-5b4c8598b5-4ztf9>
Content-Language: en-US
To: "TLS@ietf.org" <tls@ietf.org>
From: Muhammad Usama Sardar <muhammad_usama.sardar@tu-dresden.de>
In-Reply-To: <178004897406.1571084.15428249207754239073@dt-datatracker-5b4c8598b5-4ztf9>
X-Forwarded-Message-Id: <178004897406.1571084.15428249207754239073@dt-datatracker-5b4c8598b5-4ztf9>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-512"; boundary="------------ms000302070108020701010304"
X-ClientProxiedBy: MSX-L416.msx.ad.zih.tu-dresden.de (172.26.34.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: GZ3MIBO6EQLQMEDGTQD4QZCUY63CGGZL
X-Message-ID-Hash: GZ3MIBO6EQLQMEDGTQD4QZCUY63CGGZL
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] Fwd: New Version Notification for draft-usama-tls-risks-of-mlkem-01.txt
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/2LukH1riSE5PQPpMVlVGygp4lpg>
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>

Dear Joe and Sean,

I believe I have collected sufficient attestations from the WG that a 
new proof is required for draft-ietf-tls-mlkem.

As I understand, apart from me, there are at least 2 other WG 
participants (Nadim [0] and Nathanael [1]) who are /already/ doing or 
have /volunteered/ to do independent formal analysis in ProVerif. I take 
that as a strong attestation that there is enough WG energy to do the work.

So with these attestations, I would like to request the initiation of 
the FATT process for draft-ietf-tls-mlkem. I believe it would be good to 
have FATT's evaluation of the artifacts that would be eventually 
developed by these efforts. Thank you for your kind consideration.

In addition, I believe all concerns have been addressed in this version. 
Summary of major changes is:

  * Added justification based on the FATT process: Section 4
  * Reorganization, specially in motivation (Section 1.1)
  * Added some common arguments: Section 6
  * Comparison with hybrid ML-KEM in Section 4.1
  * Clarification of what "breaking" means in Section 3

For those who haven't had a chance to check the draft yet, more feedback 
on Sec. 3 and 4 is very welcome. For discussion of details of modeling, 
please contact me off-list.

Best regards,

-Usama

[0] https://mailarchive.ietf.org/arch/msg/tls/pZe6luYQeT4GhbOc1FE1xi-Lmzc/

[1] https://mailarchive.ietf.org/arch/msg/tls/S5QioGFa3T3AFWIAjsNg8BFy5Co/



-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-usama-tls-risks-of-mlkem-01.txt
Date: 	Fri, 29 May 2026 03:02:54 -0700
From: 	internet-drafts@ietf.org
To: 	Muhammad Sardar <muhammad_usama.sardar@tu-dresden.de>, Muhammad 
Usama Sardar <muhammad_usama.sardar@tu-dresden.de>



A new version of Internet-Draft draft-usama-tls-risks-of-mlkem-01.txt 
has been
successfully submitted by Muhammad Usama Sardar and posted to the
IETF repository.

Name: draft-usama-tls-risks-of-mlkem
Revision: 01
Title: Potential Risks of Standalone ML-KEM in TLS 1.3
Date: 2026-05-29
Group: Individual Submission
Pages: 16
URL: https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-01.txt
Status: https://datatracker.ietf.org/doc/draft-usama-tls-risks-of-mlkem/
HTML: https://www.ietf.org/archive/id/draft-usama-tls-risks-of-mlkem-01.html
HTMLized: 
https://datatracker.ietf.org/doc/html/draft-usama-tls-risks-of-mlkem
Diff: 
https://author-tools.ietf.org/iddiff?url2=draft-usama-tls-risks-of-mlkem-01

Abstract:

We attest that standalone ML-KEM in TLS 1.3 breaks the existing
formal proofs of TLS in state-of-the-art symbolic security analysis
tool, ProVerif. In this draft, we show *exactly* where the ProVerif
proofs break, namely transition from symmetric DHKE to asymmetric
KEM. More specifically, the existing proofs of TLS in ProVerif are
based on commutativity property, whereas commutativity does not apply
to standalone ML-KEM in TLS.

We also attest that from a formal analysis perspective, this is a
much bigger change than RFC8773bis, which indeed went for FATT review
(cf. [TLS-FATT]). We, therefore, formally request the chairs to
initiate the FATT review of standalone ML-KEM in TLS. A few WG
participants have already volunteered to do formal analysis in
ProVerif.

This draft also offers some preliminary discussion to help the
developers and policy makers make informed choices. Finally, the
draft also aims to reduce the endless repitition of arguments from
both sides presented on several lists by documenting these arguments
so they can simply be referred to.



The IETF Secretariat