[TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-11.txt

Wang Guilin <Wang.Guilin@huawei.com> Mon, 31 August 2026 09:37 UTC

Return-Path: <Wang.Guilin@huawei.com>
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 8C8961321E29F for <tls@mail2.ietf.org>; Mon, 31 Aug 2026 02:37:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1788169021; bh=X0FXbMA1Xg/GFwgNn42h/Zt+sZHSGxD5GR4zfS+LjOo=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=ZyU0qCZVYe9q9vB36Vb/UyFLoC2z+XZp3HxAfOXomSABsFnuNmEB6PpNzpz/OFV7s kP3X0a8oOc64lQ2mv5OyGzGlVYNGty1JFFqTAnupihrJiwVcGavRwzG4Tg7dntJ2tA dAHU75fI98qrAm5QLqkx8gdf/2QqUxrbCKZqr2lI=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.215
X-Spam-Level:
X-Spam-Status: No, score=-2.215 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, INVALID_MSGID=0.568, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=huawei.com
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 bKTI69CEVcAu for <tls@mail2.ietf.org>; Mon, 31 Aug 2026 02:36:59 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A1C0E1321E298 for <tls@ietf.org>; Mon, 31 Aug 2026 02:36:59 -0700 (PDT)
dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=fVUU6cNG2NvJI/yNtbP45h13TpllZlYmBjZDNK+c4Rs=; b=hKl7i/wWc64Rd1Y5/OEW7QXlkstCAERUvIJtyAyDCS9ULC/2+QIWC0M3wyLOFJnjCu9EgonHq ob9qzCTqM9iqSJOwMrSQt84kyZvwWUhQ/66EccmcL7I+SZs6WSxJgf15F3bDNe4sbhZ7nXOp1Jg to2GCKmgs2wBVcsrj2EvD1w=
Received: from mail.maildlp.com (unknown [172.18.224.107]) by frasgout.his.huawei.com (SkyGuard) with ESMTPS id 4hYP5555PTzJ4673 for <tls@ietf.org>; Mon, 31 Aug 2026 17:36:25 +0800 (CST)
Received: from kwepemh500011.china.huawei.com (unknown [7.202.181.142]) by mail.maildlp.com (Postfix) with ESMTPS id 3FB364058B for <tls@ietf.org>; Mon, 31 Aug 2026 17:36:53 +0800 (CST)
Received: from sinpemt100001.china.huawei.com (7.214.3.238) by kwepemh500011.china.huawei.com (7.202.181.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 31 Aug 2026 17:36:52 +0800
Received: from sinpeml500009.china.huawei.com (7.188.194.209) by sinpemt100001.china.huawei.com (7.214.3.238) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Mon, 31 Aug 2026 17:36:51 +0800
Received: from sinpeml500009.china.huawei.com ([7.188.194.209]) by sinpeml500009.china.huawei.com ([7.188.194.209]) with mapi id 15.02.2562.045; Mon, 31 Aug 2026 17:36:51 +0800
From: Wang Guilin <Wang.Guilin@huawei.com>
To: tirumal reddy <kondtir@gmail.com>
Thread-Topic: [TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-11.txt
Thread-Index: AQHdLxQyJfDxr2OPyEGMA++hZIVDl7atA7UwgAV6J4CABXx8Dg==
Date: Mon, 31 Aug 2026 09:36:51 +0000
Message-ID: 7A2B7FFE-30AD-419D-9789-4083CBACE2A8
References: <178705738239.532236.9732380350992727627@dt-datatracker-7c6ddbc678-lb5nk> <CAFpG3gdxmCKQkf42R=iLSKR12tafk1hFYw25N=ae5DrKtXY6dg@mail.gmail.com> <0a0f5a93229a4266ab4c46bad9131fd9@huawei.com>,<CAFpG3gej2Ji5VHq8KEudpp0aWU2OXZcP2Wwdv6C=L17C_wx-jQ@mail.gmail.com>
In-Reply-To: <CAFpG3gej2Ji5VHq8KEudpp0aWU2OXZcP2Wwdv6C=L17C_wx-jQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_7A2B7FFE30AD419D97894083CBACE2A8_"
MIME-Version: 1.0
Message-ID-Hash: RKS4S6JO3LMNFGYWZJYXKIQZFUP2PL6N
X-Message-ID-Hash: RKS4S6JO3LMNFGYWZJYXKIQZFUP2PL6N
X-MailFrom: Wang.Guilin@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; header-match-tls.ietf.org-1; header-match-tls.ietf.org-2; header-match-tls.ietf.org-3; header-match-tls.ietf.org-4; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "<tls@ietf.org>" <tls@ietf.org>, Wang Guilin <Wang.Guilin@huawei.com>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-11.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/yLICkLq0MJFOUL0Ac8FQiAoWtaU>
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>

The updates look nice. Thanks

Guilin


发件人:tirumal reddy <kondtir@gmail.com<mailto:kondtir@gmail.com>>
收件人:Wang Guilin <Wang.Guilin@huawei.com<mailto:Wang.Guilin@huawei.com>>
抄 送: <tls@ietf.org<mailto:tls@ietf.org>>
时 间:2026-08-28 13:50:51
主 题:Re: [TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-11.txt


Hi Guilin,

Thanks, I agree with both comments; they are now fixed in PR https://github.com/tireddy2/composite-mldsa/pull/17.

On SUF-CMA: it isn't about the traditional component being broken. A composite is SUF-CMA only if every component is, and for instance, ECDSA isn't, so some of those composites already fail SUF-CMA today.

On the second point: the text now has the attacker deriving the private key from the traditional public key in the server's existing certificate and becoming an on-path attacker. No certificate forgery or CA compromise is required. I also  added another threat vector: an attacker that derives a CA's private key can issue certificates for any name, which also affects a server that has already moved to a composite certificate if a traditional CA is still trusted by the client.

-Tiru

On Tue, 25 Aug 2026 at 12:09, Wang Guilin <Wang.Guilin@huawei.com<mailto:Wang.Guilin@huawei.com>> wrote:
Thanks for the update.

Read Section 5 (Security Considerations). The following two parts could be improved, I think.

"However, composite signature schemes do not in general preserve strong unforgeability (SUF-CMA) once the traditional component algorithm is broken, for example due to the availability of CRQCs. "

This description seems not really accurate, as composite signature schemes [I-D.ietf-lamps-pq-composite-sigs] do not preserve strong unforgeability (SUF-CMA) as long as either of the component signature algorithm is not SUF-CMA, not just in the case of "once the traditional component algorithm is broken".

But I do agree on "This loss of SUF is inherent to the composite construction and does not impact TLS".

Also, the following is just an attacking scenario for an adversary CRQC.

"TLS clients that support both post-quantum and traditional-only signature algorithms are vulnerable to downgrade attacks. In such scenarios, an attacker with access to a CRQC could forge a traditional server certificate and impersonate the server. If the client continues to accept traditional-only certificates for backward compatibility, it remains exposed to this risk."

In my understanding, a more natural and better hidden attack is to either compromise the server's private key or forge a valid signature w.r.t. the server's existing traditional public key certificate.

Cheers,

Guilin

From: tirumal reddy <kondtir@gmail.com<mailto:kondtir@gmail.com>>
Sent: Tuesday, 18 August 2026 9:18 pm
To: <tls@ietf.org<mailto:tls@ietf.org>> <tls@ietf.org<mailto:tls@ietf.org>>
Subject: [TLS] Fwd: New Version Notification for draft-reddy-tls-composite-mldsa-11.txt


Hi all,

We have published a revised version of the draft: https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa. This revision incorporates the feedback received from the WG. The main changes include adding the missing composite algorithm based on the selection criteria in the draft, clarifying why the loss of SUF-CMA security does not impact TLS authentication, and adding downgrade security considerations.

Please take a look and let us know if there are any further comments or issues.

Thanks,
-Tiru
---------- Forwarded message ---------
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Tue, 18 Aug 2026 at 18:19
Subject: New Version Notification for draft-reddy-tls-composite-mldsa-11.txt
To: Tirumaleswar Reddy.K <kondtir@gmail.com<mailto:kondtir@gmail.com>>, Daniel Van Geest <daniel.vangeest@cryptonext-security.com<mailto:daniel.vangeest@cryptonext-security.com>>, John Gray <john.gray@entrust.com<mailto:john.gray@entrust.com>>, Scott Fluhrer <sfluhrer@cisco.com<mailto:sfluhrer@cisco.com>>, Timothy Hollebeek <tim.hollebeek@digicert.com<mailto:tim.hollebeek@digicert.com>>


A new version of Internet-Draft draft-reddy-tls-composite-mldsa-11.txt has
been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:     draft-reddy-tls-composite-mldsa
Revision: 11
Title:    Use of Composite ML-DSA in TLS 1.3
Date:     2026-08-18
Group:    Individual Submission
Pages:    16
URL:      https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-11.txt
Status:   https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/
HTML:     https://www.ietf.org/archive/id/draft-reddy-tls-composite-mldsa-11.html
HTMLized: https://datatracker.ietf.org/doc/html/draft-reddy-tls-composite-mldsa
Diff:     https://author-tools.ietf.org/iddiff?url2=draft-reddy-tls-composite-mldsa-11

Abstract:

   Compositing the post-quantum ML-DSA signature with traditional
   signature algorithms provides protection against potential breaks or
   critical bugs in ML-DSA or the ML-DSA implementation.  This document
   specifies how such a composite signature can be formed using ML-DSA
   with RSA-PKCS#1 v1.5, RSA-PSS, ECDSA, Ed25519, and Ed448 to provide
   authentication in TLS 1.3, including use in certificates.



The IETF Secretariat