IETF Logo Mail Archive

[TLS] Re: Composite ML-DSA

Filippo Valsorda <filippo@ml.filippo.io> Wed, 15 April 2026 12:45 UTC

Return-Path: <filippo@ml.filippo.io>
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 037D7DCBC7DF for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 05:45:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776257101; bh=WkwTFgKg8bGhUTFzo/z7P2Lg6QH1rVSet260u/JQNM0=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=GxXhshkYBYzoSmVEvsnUcLb2OmEXY9iMWBmg2+5egZW0M/CzcVP0PWRAYYReUmS7A nmpqd3ZBlBCU6ro0qk/s3jpg20KuVtlqA7L5kGEvXzXQnO8YfQ6jDg2U6JrSN/xYu9 FkabjwGa0ryK4kFmeqON2dkoky0RR++owqueg30k=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=filippo.io header.b="OoQZJa8g"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="FGOGWEr8"
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 h97HKEWdmn5J for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 05:45:00 -0700 (PDT)
Received: from fhigh-a1-smtp.messagingengine.com (fhigh-a1-smtp.messagingengine.com [103.168.172.152]) (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 F3BF4DCBC6A5 for <tls@ietf.org>; Wed, 15 Apr 2026 05:43:46 -0700 (PDT)
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfhigh.phl.internal (Postfix) with ESMTP id A42AA14000E3; Wed, 15 Apr 2026 08:43:40 -0400 (EDT)
Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-09.internal (MEProxy); Wed, 15 Apr 2026 08:43:40 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1776257020; x=1776343420; bh=/lOvjwSYTU hstoHHA+N3d62C4IEBOxrB3KtaY7qza9I=; b=OoQZJa8gG16/rtj3p3GH8VSv+B Fkq/IXr1Wt2ancEoM0b5gxUL/3JDDmnTVypB+v2UEeSq8fvxyyjYh5HEOZBJjMin Ka0CiY6MDOFZ+4DzOito0iYjEMk+kLJxJsovYBYpGiGXrSo3OWVFiHuK5VC1/Gwr b/+PJnHu2AhoroPU3khRmGsQODO7D1NNcASiYuyDSBNS8D00tKLFEUWocGzmAGRE sMKOTccY4H6yw2TnxWeir1ch1zBtFAmjonM1n5/yDBoTuPVCizKShSn9FVuj4g5e w8U9FtLLLlYJC7LFN7h2XmcWyGbeyi0VxQKEgk8zAQl/Rw3yN9s1wPHM0Dqw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t= 1776257020; x=1776343420; bh=/lOvjwSYTUhstoHHA+N3d62C4IEBOxrB3Kt aY7qza9I=; b=FGOGWEr83bRWRISUa7cyBRmAxXZ+yILtdx27q+egTVKlFePbOxQ Ff8nO4gxJ4DTqAsoX+kfha8uasGQabBq0HNakNpkcvRoJDtP0BtfHZYXEEnbJfkX +O0krb2g4uKaXPmeGheiu9NTXlGj/IAsFe92y2OsXR5TybcuMwG5L56AVG00BjOY WBJkLbhVB1sSjXx2v1vD2LiwFt8d80VzLWcA+pD+z5rf4mA0ED8untLA6tuacW/T HmBut9TxqWf7n347Z/JoV+HX/BojGTBjLZmFGh8r+pQaPlL/S827gxU3wCLE2yz5 fRLzs6eSkTbyuzDBattPHjaOYZ9n6k6rvZA==
X-ME-Sender: <xms:_IffaffKX_fM41zJ1nmFL4Q82iALVSOGaY_cq0VFrSdoownE0bN0Zg> <xme:_IffaQApZo1qP0MfAIVgEq1AHax0qVmVKrPfLNmDtvwa2bBRk5V3Ua-k1dEfNi5yQ aoNOMWkNGQX3_fAKkCzlhpUMTGbbro0CSNbVB721NdY41Om6IiWzQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdeggeduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepofggfffhvfevkfgjfhfutgesrgdtreerre dtjeenucfhrhhomhepfdfhihhlihhpphhoucggrghlshhorhgurgdfuceofhhilhhiphhp ohesmhhlrdhfihhlihhpphhordhioheqnecuggftrfgrthhtvghrnhepieelgedvgefgje fhteejgeelgeeigedvudektdelleeghedtvdfhgffgiedvffefnecuvehluhhsthgvrhfu ihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfhhilhhiphhpohesmhhlrdhfih hlihhpphhordhiohdpnhgspghrtghpthhtohepvddpmhhouggvpehsmhhtphhouhhtpdhr tghpthhtohepkhhonhguthhirhesghhmrghilhdrtghomhdprhgtphhtthhopehtlhhsse hivghtfhdrohhrgh
X-ME-Proxy: <xmx:_IffaXfUiyyqKHo3kJO9RIvrt8EX9130Q4qc9750m75qAPLkBd9f2w> <xmx:_IffaTMAtIB-aHVH07yxVKdXi1x056JX_9euGKpiiLWrQy0Y3L7XAw> <xmx:_IffaeLdHiIFzhLo7T0YJF7Fu1mS1OqEIFr2nAfC3zfyQsyIF7wJqQ> <xmx:_IffaUHOr_It17MsQM69QkssuMvRgteVlRJ0SBjp16zvPeq0xbu2uQ> <xmx:_IffaVGw1yEaNVDFKXI4bycUHVvSqF9MMupsgncntrIdj_bEVOTXuibO>
Feedback-ID: i2e91459c:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 6DFE0700065; Wed, 15 Apr 2026 08:43:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: AG1t3CG6vdx-
Date: Wed, 15 Apr 2026 14:43:19 +0200
From: Filippo Valsorda <filippo@ml.filippo.io>
To: tirumal reddy <kondtir@gmail.com>
Message-Id: <d69ba150-0257-4e64-9abb-9229d03a03a6@app.fastmail.com>
In-Reply-To: <CAFpG3gcC+UfO7E=ADGhwr2En5PwipZiq_r6_RdqvmT-5nnh2jw@mail.gmail.com>
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> <CAFpG3gcC+UfO7E=ADGhwr2En5PwipZiq_r6_RdqvmT-5nnh2jw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="5494ba811c7788ea8feadb446b8960e383f12d52"
Message-ID-Hash: 2OCISAZLOP357WKF6CIEPKLSRT5ZFWQ7
X-Message-ID-Hash: 2OCISAZLOP357WKF6CIEPKLSRT5ZFWQ7
X-MailFrom: filippo@ml.filippo.io
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>" <tls@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: Composite ML-DSA
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/oh3jmmkHzHdp1hk4R4M9QjkmvBk>
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>

2026-04-15 07:45 GMT+02:00 tirumal reddy <kondtir@gmail.com>:
> Could you elaborate on the reasons behind this position? Understanding the specific objections would help us address them in the draft or in the WG discussion.  

I think hybrid authentication is firmly on the wrong side of the complexity / benefit tradeoff.

The benefit is a little lower than hybrid key exchange due to the lack of store-now-decrypt-later risk [0], but that's not the interesting side of the tradeoff.

The complexity cost is vastly higher than hybrid key exchange for two reasons:
 1. Composite keys leak all over the API and application/configuration layer. Libraries need to define structures and types for composite public and private keys. Their format needs to be standardized. Web servers and system administration tools need to support these formats. OIDs need to propagate from the TLS stack through the X.509 one. Deploying ephemeral hybrid key exchange required none of this: it was a self-contained, fully abstracted change in a single piece of software.
 2. The mechanism they fit into, X.509 authentication, is already way more complex than key exchange, and more prone to mistakes. Just last week WolfSSL disclosed a vulnerability (CVE-2026-5194) that let _anyone forge certificates_. It's described as having to do with hash lengths, but one of the root causes is incorrectly handling a signature algorithm with pre-hashing (ECDSA) and one without (Ed25519 or ML-DSA), which led—along with another bug in matching issuer/child OIDs—to checking an ECDSA signature over an empty hash if the leaf claimed an Ed25519 signature. In hindsight, the Ed25519 design of taking a message instead of a hash was a mistake [1]: it mitigated no collision attacks against hashes, and contributed to at least one critical auth bypass. Preventing those *is the whole job*. Now it's just "what if lattices are broken" instead of "what if collision resistance is broken" and composite signature types introduce significantly more complexity than no-pre-hashing signatures to mitigate that hypothetical threat.
There's a reason the immediate chorus of "hell no" came from (most of) the implementers.

Overall, I think composite signatures are a net negative, will hurt the ecosystem, and should not be implemented. But I also don't believe in the IETF being a gatekeeper for implementing/deploying things, so I have no opinions on what does and doesn't become an RFC. (In either direction: I don't care if a thing we implement is not an RFC, and I don't care if a thing we don't implement is an RFC.)

[0]: It's also late in the game. Composite signatures don't exist for deployed values of existing. Maybe if they existed two years ago, they could have provided more benefit. Maybe. But they didn't, and I think they didn't in part because of how much more complex they are. Now there's significantly less uncertainty to hedge.

[1]: The right design for both Ed25519 and ML-DSA would have been to pick *one* hash, and define the signature algorithm as taking a digest of that type. There was even an obvious answer: SHA-512 for Ed25519 and SHA-3 for ML-DSA. One mode, easily enforced fixed size input, easy to test, compatible with hardware interfaces, fits the existing pre-hashed APIs. Alas, that ship has sailed.

> -Tiru
> 
> On Tue, 14 Apr 2026 at 04:33, David Adrian <davadria@umich.edu> 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. 
>> 
>> On Mon, Apr 13, 2026 at 3:51 PM Filippo Valsorda <filippo@ml.filippo.io> wrote:
>>> __
>>> We have no plans to implement composite certificates either.
>>> 
>>> 2026-04-14 00:20 GMT+02:00 Watson Ladd <watsonbladd@gmail.com>:
>>>> I do not think composite certs make sense for TLS.
>>>> 
>>>> On Mon, Apr 13, 2026 at 12:33 PM David Benjamin <davidben@chromium.org> wrote:
>>>> >
>>>> > On Mon, Apr 13, 2026 at 10:51 AM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
>>>> >>
>>>> >> On Mon, Apr 13, 2026 at 04:30:34PM +0000, Andrei Popov wrote:
>>>> >>
>>>> >> > Just to weigh in on this: I would support adoption of
>>>> >> > draft-reddy-tls-composite-mldsa. There is customer demand for
>>>> >> > composite certs, and I would like to get these implemented in the
>>>> >> > Windows TLS stack.
>>>> >>
>>>> >> I don't know what sort of interoperability you are expecting with these,
>>>> >> I am strongly inclined to NOT implement any of the composite signature
>>>> >> algorithms, at least not in TLS.  It may be harder to fend off their
>>>> >> adoption in CMS, but ideally sit that out as well, until we either have
>>>> >> CRQCs and hybrids are pointless, or we don't have CRQCs and know why
>>>> >> we're never going to have them.
>>>> >
>>>> >
>>>> > We're also not planning to implement composite ML-DSA in TLS.
>>>> >
>>>> > David
>>>> > _______________________________________________
>>>> > TLS mailing list -- tls@ietf.org
>>>> > To unsubscribe send an email to tls-leave@ietf.org
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Astra mortemque praestare gradatim
>>>> 
>>>> _______________________________________________
>>>> TLS mailing list -- tls@ietf.org
>>>> To unsubscribe send an email to tls-leave@ietf.org
>>>> 
>>> 
>>> _______________________________________________
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-leave@ietf.org
>> _______________________________________________
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-leave@ietf.org

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