IETF Logo Mail Archive

[TLS] Re: Composite ML-DSA

Daniel Van Geest <daniel.vangeest@cryptonext-security.com> Wed, 15 April 2026 15:33 UTC

Return-Path: <daniel.vangeest@cryptonext-security.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 B8B4BDCD93BE for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 08:33:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776267203; bh=OoOBwfMBAQcMj3W3BmSRihXwlrZfeVMWsP9hHAUcNsU=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=BfRKAC278PvZupf6b+f/vWcvoBeZOJ8CsJwaxwpcoy9SDz0IdJgJko5XxrGeZ1APi PH/B592/ALwk/i5vAl95j1tqdGLAdhdAYvG2Ie8ITfRZfFn4XjoVgnC7Jgu0XZw2Pr xQGuFB+RzZEDItmxr9AFX41ttpE+GXZLeA/y5TUE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=0.001, 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=cryptonext-security.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 LJLO9mfo9Z5G for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 08:33:23 -0700 (PDT)
Received: from PAUP264CU001.outbound.protection.outlook.com (mail-francecentralazon11021128.outbound.protection.outlook.com [40.107.160.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B896ADCD93B7 for <tls@ietf.org>; Wed, 15 Apr 2026 08:33:22 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=jiQxEXZwEi6nbTPMhXn/Kjlhc3a6ZKOJnNB1gQmnjK5cGm8XLCS+i7Qo6HiRT/nj1GxWJdxF5pI/I9jGAy44PWoa1L59Ut345rcFuq768wwpnrVuwlJ6bvuj5jQ6aXI88RS0f/p/d2ouN1+iyRQrrNQTTV02IckNDaMAX3TgjcQb2P7x4NfcuOiRqgoP8eh7Wir/lNJfd3asaSefBwr275T9QyV+98BhcudCiDgIrllQt5xjax1b1ZXrETtqs7h9/p8o3R8g28h3ZCIai7P3jIoEouN1WNvSve86cYTiwnCPl/uF+/XQ82QyfmmjVOWc83bI7GzsNnIRnmo3S/cVnA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OoOBwfMBAQcMj3W3BmSRihXwlrZfeVMWsP9hHAUcNsU=; b=ItmuS5s7g0ut9bpauAGq16EK0n+7mucl8zu7U48WN54eqms1qzs7/LYEYKFpdxG8+E+x2G2raxFuXbyy7S8iW3L90GvdDz+OVN6ddU0S5DbbLdfqpB0//3oDdU9D/xcxpw/hXmp30KwQupwwknQoiajx1jPTAnOamlrIBqKaOwy2qN/KNRxv/eHH7OqOtTOFfoCIfsxS7we4I/7DEhD9xOgaoFPq7fT0HU4Exd8s/i0zGMYomDHJ8w0ReIxq3ldbtMjKyQqbJwPcbDC8ppfBk0OkGgzYdZoD4aFZC7AJHJamc+LnkqllUvGtRzfv3OoqDq+eO+j/svLloJ5wiFeBxQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cryptonext-security.com; dmarc=pass action=none header.from=cryptonext-security.com; dkim=pass header.d=cryptonext-security.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cryptonext-security.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OoOBwfMBAQcMj3W3BmSRihXwlrZfeVMWsP9hHAUcNsU=; b=h7G1s6AJxtr6ieEr6LIM7HwFRzlJG+13VpWUhM9vjTI8f9m3mq7EW1pC81wuIUYEGAwMgdNPUsnLBlGiUAroPXBs59phyKEA4H52xQBfofGn285av80pxdMwrME4WkYuk3FKM1U+ykrmpT6M8lfxMu4PTT5CSQk22QDuHI/xJymZ5HSfaXM4/wAKjphokoV3zJhC1nTkOnJpHQR8NmuZz5xMHspShnLCTNItxvyxOTzgWoirZQVL8BmRfuQAhaV8RebJXYfYZInTMOac9W4W9EJ+TjhBbmqjn0YipZ9jko94fWYjWL55xtQ3P4lauPo+iQ+72hDgDEq70wdz6O1h9w==
Received: from PA0P264MB6925.FRAP264.PROD.OUTLOOK.COM (2603:10a6:102:55a::5) by PA3PPF16D901888.FRAP264.PROD.OUTLOOK.COM (2603:10a6:108:1::618) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9769.48; Wed, 15 Apr 2026 15:33:14 +0000
Received: from PA0P264MB6925.FRAP264.PROD.OUTLOOK.COM ([fe80::87e8:c70b:3b90:e83d]) by PA0P264MB6925.FRAP264.PROD.OUTLOOK.COM ([fe80::87e8:c70b:3b90:e83d%5]) with mapi id 15.20.9769.046; Wed, 15 Apr 2026 15:33:14 +0000
From: Daniel Van Geest <daniel.vangeest@cryptonext-security.com>
To: Filippo Valsorda <filippo@ml.filippo.io>, tirumal reddy <kondtir@gmail.com>
Thread-Topic: [TLS] Re: Composite ML-DSA
Thread-Index: AQHczJtZg6Tgs606wkKBj0YG6pugRrXgEaiAgAASxfA=
Date: Wed, 15 Apr 2026 15:33:14 +0000
Message-ID: <PA0P264MB69259DDB3DA252DC57E4B4EBB6222@PA0P264MB6925.FRAP264.PROD.OUTLOOK.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> <d69ba150-0257-4e64-9abb-9229d03a03a6@app.fastmail.com>
In-Reply-To: <d69ba150-0257-4e64-9abb-9229d03a03a6@app.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cryptonext-security.com;
x-ms-publictraffictype: Email
x-ms-traffictypediagnostic: PA0P264MB6925:EE_|PA3PPF16D901888:EE_
x-ms-office365-filtering-correlation-id: 4e3d3f06-d346-49c5-ca0c-08de9b044f19
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;ARA:13230040|376014|4022899009|366016|1800799024|38070700021|18002099003|56012099003|22082099003;
x-microsoft-antispam-message-info: uNMnL2q66zBMh8lJw1OpGerejHF931cNgJqfS/HccxZzIwFYaL2QjIoYPxg+8IMKYqW0DSODKOduw6xrm0+KBn6UUOd0DdIkKxjujpS6IPfrVSPDyb612XLBYoW5KMnNJmwKkNuogUPqLL0j5SjfgXdQ9R9mPV62Bo2Z0lYp19Axs0zHY2nnIzIaHxvcJtSB6M1nw7CEf2KVcqhXfmm4ONf/prNCQkPzYRJdQW7PgWIVwJYVvqYEHWhEX58oooQtBO1w74qzYzMOUCEkASxEnTFeTXlpv6Ebed6bzE5RGoXIuQg7wxNxvRIBrMFd+1VoE6X4eKzQKHj3TStsaHO6BQ4pbpwdUB61hdF4Ruhrvd1HfXq/wUpN08pFuAXyvLJGFkltlFxtq7QruVHKiGKE/UB3fTc0fNUHau6x0VSAq6as9zptq7ti+3O3Kpx2WHTTJLGItV/hCP9nTnWxVkInsaMiQgHRTm7Pk8giVHiQre64dy4avXie6iy5jrykWJf633xdrnoNjjP3TrmQOO+jVkPd8WUZbRpqKjW6BKEJBHNtVtK0yB/vNQrtm/387uusJ3KxZOPMIkOMDe9YDO8bsnijiOfaLOr6MUTPAoyxVpxiZ4K/SPkccE2I97o0AzLxDzJ9qD07HwY9qVe8EnMtqpWg2KVmRMSt9jrb0D/1LxvRkdnkJ8dvubPwyarK7itAR3JgRXH/Gr1R8GGLnKEk4f5D4B3F4HGm6U0KUkyCPMTcwUBkh/DHqjqn5s4YcPzA5052D4o9RwgxRh4w8cas21o0IvxiTt09xQ6CWqvSNr0=
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:PA0P264MB6925.FRAP264.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(13230040)(376014)(4022899009)(366016)(1800799024)(38070700021)(18002099003)(56012099003)(22082099003);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 5AIvzkJ6noAzheXCIGAbxZUybZAGis4GTw9oC3m7UniDNSZX2XNH2BA7fIt0Uu0agIgdx5Fot+JMUhUnQIIV0qk0Au7gSNZyLQ4N8Yd6pElsRe8wGQQAYe/OGnbNSB8Y7do91xjWrBiF+vMqbFSrYxwv12Slm51PhaFkRJya4nSTjF/xsrb/c5GsQe5QFWIJaVOAga0ZCdmIlYH3wTxDODXw9JzdYk/+6r9OZU636f/1hPDyS46An4xfjzTT+olfNc0gxEFX201/lWr10kia6z6ld4f3HpKuJxEwqrSqW9FnrSHTyyR5IfRo8HWx6rs3vzA1M8puvB/UTWFwRZNFutkgjMjIBJCqAD01tMCgCimuxBZMVHNASHr5d6/lnXwjTLj6sJ13rBSvK3bd2D/4+hCKQtPsx7EyyTz0bYM8Dm8bQRDPj1cf/IGTYwu6aLkSmh8WHtuVKlXxwK0AdTcjhzKFQ5dpN9sTG7gn7s4nXg/cidVWa0hEzTrE4v7naOXIMU4Q7FBa3g9LwzTP9gOHJK/au4yF4OsSxLUXWuOX5ETZguSHqcTuGpe4H5T1A4X/ZGA7N0+GQ2m8w29nPBtQEIIRkwmkou/h/nzeXItMTJE00ue201FgAKY+vaEJHsJMCajEnE9RgIv51o64VOFYzDuNJu5jmtWlB6oNsX8yUD6IG3TZziAP/cz+tpEYSspIio8Fl/TWNxlHdtv7gXL3CT14eyv7D99flHaUAAh6QySmaGMBz00ykK8l8/BKEng07SJCLEfzoMbtGJW8A77BlUYNNxe7Ia34lRFp/vSv0UkY/V/0oaLCX7UiqQLqCDRty17yGNqv2CiMK45ngdX1zhnmMjjf5Blif3MSexMKpO1IOGkRSrppDYh9dJx5oVxSnZ612lfj+iejY4nfCcGRdnFftyUZxeaihU0NC0UR1fKGeOEefk/xavYaNcLwoyuqppga8qnBUEL2VqyvsQcLwMGADQSSzY9bjOtEIjKKeFL6Mh08V3jiYDgnZAGi8o3cCA+sjOALGnnps7qfpMgObxD+IJurhOoj/9gobTn7K+BPQSYRMCV9eumwIxY/xxANeyil9zggbBM+ZcuAB6oDqza/FRgvydL+qvtfsSK1szNcNtxOr4TXnioSq1yrweXwC1NWEi+Ij7owZHAcINC6J2EIQpNHtpjK/IwDZBUAZVzmCTsKJj1mjw7hYal1evT39taodcsEVphiucR/+KCJd7lqgNUQshQlIxn86KpMVOgXYsGkzPlDvdgeIs2yVeIevfykzmNC9jWxTlTtBMmg/trHgzDPL9nqAfiOeBUm7H5g86eOxCQsizJaza3aeGAliz8sMmfdi56bL+/vpZBPbUp/RZSECYoQOqDZBkP/d8mZNpedk4MlLyPLfC3frh6dDvEL9enElM5ik7GLmYwz9Qt6EtHL1/6jxcXqSiY3y4/03UhHyCSUbshE3DqIVGWnYHZp4tcvg/fqETmm4UZOUmK1hy6nmz2HN+V0xcFsDP9RxlSPgRs0epYoTV2+hlm4BxCJFs0UfWbNpuZex3Nx/m0cAt7O0I7l2TODeVPMk7rOaluZUFR1RqVUxsC7QmOmxgpAikItaUbAMq+Zh317hh3LZ3g9/kx3pz0k6ihbX59bjKF75S6/8BYWPeWnMuOcsvv6ei2tDeKsOE5PIMN8+a9gSBI9Ad67KiFgYszUPA6tu3GSxGRm6QGxIATroMYr1EuW2q6AJsU/kccB+qa31llmE023moUYOvl6XbiJYw+n5Xh4b8Z54sIi9sPjBAse
Content-Type: multipart/alternative; boundary="_000_PA0P264MB69259DDB3DA252DC57E4B4EBB6222PA0P264MB6925FRAP_"
MIME-Version: 1.0
X-OriginatorOrg: cryptonext-security.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PA0P264MB6925.FRAP264.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: 4e3d3f06-d346-49c5-ca0c-08de9b044f19
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2026 15:33:14.2259 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: da4a2df1-4b1b-489d-a7f4-224b58fd4200
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: lc0JzuuvwHiw7qFSkawAEORDCcIH31wEb8v98yPgeY4Dtm9QgP/YtxnSecsODME0ceztIKJghrg0/x6L/4+TeckdImTfJ3/7J1BSb4c4NtzxlCTeKQJHcMiZOIs+gnfZ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PA3PPF16D901888
Message-ID-Hash: UA553LNNQ5NPAGA4L3AXMQIRG2DYXBS2
X-Message-ID-Hash: UA553LNNQ5NPAGA4L3AXMQIRG2DYXBS2
X-MailFrom: daniel.vangeest@cryptonext-security.com
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/R76Itj8rfAMoVjtA8XnUrqYthlw>
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>

I don’t expect this to change any minds, but see inline for my comments, as an implementer, on Composite ML-DSA.

This is not directed only at Filipo, but he had the most complete set of “it’s too complicated” objections.

TLDR; Any Composite ML-DSA combination presents as just another signature algorithm. Yes, there are too many Composite ML-DSA combinations.  That is independent of the complication objections and is easily remedied in TLS by defining a subset.

      _____________________________________________
      From: Filippo Valsorda <filippo@ml.filippo.io>
      Sent: Wednesday, April 15, 2026 1:43 PM
      To: tirumal reddy <kondtir@gmail.com>
      Cc: <tls@ietf.org> <tls@ietf.org>
      Subject: [TLS] Re: Composite ML-DSA


      2026-04-15 07:45 GMT+02:00 tirumal reddy <kondtir@gmail.com<mailto: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.

Not Composite ML-DSA. Any Composite ML-DSA algorithm (e.g. id-MLDSA65-ECDSA-P256-SHA512) presents to the application/configuration layer the same as any other signature algorithm.
draft-ietf-lamps-pq-composite-sigs defines the following interfaces for Composite ML-DSA:
-       Composite-ML-DSA<OID>.Sign(sk, M, ctx) -> s
-       Composite-ML-DSA<OID>.Verify(pk, M, s, ctx) -> true or false

This will look very familiar to anyone who has seen FIPS204.

            Libraries need to define structures and types for composite public and private keys.

Not TLS libraries.  Not necessarily X.509 libraries.  Wherever you define your structures and types for RSA and ECDSA you can do so for Composite ML-DSA.

            Their format needs to be standardized.

See draft-ietf-lamps-pq-composite-sigs.

            Web servers and system administration tools need to support these formats.

No more than for ML-DSA.

            OIDs need to propagate from the TLS stack through the X.509 one.

No more than for ML-DSA.

            Deploying ephemeral hybrid key exchange required none of this: it was a self-contained, fully abstracted change in a single piece of software.

I have implemented hybrid key exchange and Composite ML-DSA in TLS.  All of the work for both was done in the same 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.

Then it’s a good thing that each defined Composite ML-DSA combination picked one hash and defined the signature algorithm as taking a digest of that type. That’s what the -SHA512 is in id-MLDSA65-ECDSA-P256-SHA512.
      There's a reason the immediate chorus of "hell no" came from (most of) the implementers.

Have those implementers read a (not even that recent) recent version draft-ietf-lamps-pq-composite-sigs?  Earlier versions of draft-ounsworth-pq-composite-sigs or draft-ounsworth-pq-composite-keys were complicated, with Generic Composites, N-composites, M-of-N-Composites (maybe, I can’t remember and I won’t go back and read every version), which understandably got a “hell no”.  But the authors and LAMPS took that feedback and produced something much simpler.

I can only speak for myself.  I implemented Composite ML-DSA in an OpenSSL provider and it Just Worked.  No X.509 changes.  No TLS changes. Just private use TLS codepoints which the provider presents to the TLS layer.  If your libraries don’t do that, then you have to add some (codepoint, OID or something) entries to a table.  Just like for ML-DSA.

Daniel

      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<mailto: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<mailto: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<mailto: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<mailto:davidben@chromium.org>> wrote:
      >
      > On Mon, Apr 13, 2026 at 10:51 AM Viktor Dukhovni <ietf-dane@dukhovni.org<mailto: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<mailto:tls@ietf.org>
      > To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>



      --
      Astra mortemque praestare gradatim

      _______________________________________________
      TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
      To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>


      _______________________________________________
      TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
      To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>
      _______________________________________________
      TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org>
      To unsubscribe send an email to tls-leave@ietf.org<mailto:tls-leave@ietf.org>
       << File: ATT00001.txt >>

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