IETF Logo Mail Archive

[TLS] Re: Composite ML-DSA

Mike Ounsworth <ounsworth+ietf@gmail.com> Thu, 16 April 2026 18:31 UTC

Return-Path: <ounsworth@gmail.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 4DD0DDDCA162 for <tls@mail2.ietf.org>; Thu, 16 Apr 2026 11:31:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776364275; bh=y3R6tvsMxT9XtaIci94RhXQGpUhPblEFg8oeSEN2C4s=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=NCQqkoeCu/9/8sgompvH9q+a5ajPSt1bZCjl+5+/VFMzfIm1K0Obgwja8wzbF3szk flz2TFC/c+a9+psBOGYxIhwUlBa064Zn1ZwKprTbYzJFkl189xspRFuhEW2GG4GAEr jUfA62nNe9pYsdhgPnWFdbd+6QthtZJKVshSsLdY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=gmail.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 xqzi9RL97lkm for <tls@mail2.ietf.org>; Thu, 16 Apr 2026 11:31:14 -0700 (PDT)
Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 86B5BDDCA14F for <tls@ietf.org>; Thu, 16 Apr 2026 11:31:14 -0700 (PDT)
Received: by mail-oo1-xc2a.google.com with SMTP id 006d021491bc7-685013eb590so678152eaf.1 for <tls@ietf.org>; Thu, 16 Apr 2026 11:31:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1776364268; cv=none; d=google.com; s=arc-20240605; b=Za0Xn2XBexvu7xwCrbXnwFbkdPajkciE2hTtkhFMd8KwLTX88FRhi8uS67hqh1kLF4 A7F8X4VyFOFCGMTFOSvdT0301bZr9n7GmkgpbrCe45cqKkO11QZtdYor7sRvOPtf5kJv R0OlTagXgvY1P+HcVq17vPa1OynxXap1OtyO336I9EVOxxfwFNPmRyrBK9Adr2PPxXW6 0oPnebYV8S/O7Qt0z6qicduItOKI6Me6bJEZQ7WS6OjuHbre7toPkBvey59v1gqaaHFy 32/m5cjkQmLJR0Wj6hGC28yQ/9V9cpnOihDkBiNnOY0XL3aUdQ2oqMbA9gjdNhs/6AvB pNcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=JP64w+Zhrz7FQ/Ay3MC3WZQ5qpiTWdlyV6NVzH2qu1Y=; fh=na2MSiJYp3CEeZF87vD6aDuHjjNlvhuI4Jg1OyzshO4=; b=UzUniqpE+O/z0ID6lrtkz6k2ldJtAWf3OAW72AOHRrnKfUQsNMHe6q5DZ1ebCCLyVO nRXuDpe307Ul0eH7s6FaC5oydly34XUsSV9C1eH2GXtk4Q3BjGHvKaeJ1gngL9c40jSk qNG/6mkKrgveycmjqC2oaNEhpTUxKJ9G85y/PmJWM0UepzhvSayW3MdJB9lYIEaUhPBW pcScJrOycbUId685vrxi4kMqG4rTaihbctmfyFe5F9nBlCRi63r3M4G8Y6Giszn6G8X6 SGhPf5a+iMdJ/e513uFSanedP1go1bMhR4afsezqhR1CgORp6MF+ANe9U3MXM4UX6sTf 97Vw==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1776364268; x=1776969068; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=JP64w+Zhrz7FQ/Ay3MC3WZQ5qpiTWdlyV6NVzH2qu1Y=; b=JG/dHswml7GfuJuqSsUJaIjgU5mo7iJx31dxZWkBsbF+5atZR3uO1/Fkrq6NQ7Ao/n d+HNgdC88ZNX8zwJkKePl8rZNhnrjy5fpyMdZcOSpwT93NZ1VZP/Xaq+vrsgGHtgkB1v 2LOQEj8Sp2klboR8/gDJH77OAG7tNGqRtvZj1iK0rEIeJzgeQNsXxRfcXICavHMdV0Fk cVL6wyBHPNdJov4X7LauWnp3OGCJx2DAQFvugR8JcWpXKNrN7mmMq7uCMq9F/M5f1Prt KoGprqY9wRQSgewf+kDG6DJnreMpfU8hgBV4XKJwnnLleoS3tRRELn7I2X0ukuPqg7bt mzsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776364268; x=1776969068; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=JP64w+Zhrz7FQ/Ay3MC3WZQ5qpiTWdlyV6NVzH2qu1Y=; b=k2uq2KaSh7cVL8XdC8Wzm61Qj+hLp2cLLnbv0A0iDCH3tk6QrLLTQUlXfzuBEh6JlW ro40dUWISSn1+MyZBjOOD+eN20AmyQ/NMX9eCiosDWruZ+OXF3l4fxOlYWL6l/MACIC6 +pj3sMPbD1vnS0aYtLGqybqTuycnpigtYr8FlDwrMsQmDfUGeZvrbvWzbvkxBd3Jls/N Nc1Q8Am4NBcE+d/f2Uj0NKATOOMXdG6xhCpd0ohiKmPWnHjGQLcCPKkM7UdQ4XOlLrHR BaMj6xJwIKH3lp1RoYIG1ArzJ3y32BVKEa+UpsK5Jv3QX1lRc9sSeM6lPbjcCsFhj2V8 C6ew==
X-Gm-Message-State: AOJu0YxlRfo2sioa18WokgsQDJPOrurxw4wSdqwCUPzmFFmoOsi38hhg xVP3xBufBuPbnLfUjhlZSLJA9zkoc2txY0spierJozPD/1OHbxGhzSV0wQnlMJ+y99rebyyL8mK E8fcvKg7q1DodkU+dSedWhtefI6yVHRrFJXYW
X-Gm-Gg: AeBDietXkKRVsrOPe4j75Nj5iY61jBF1nxjnVF73XfNjQEVQxL8huKNpP8h+Lm2qSUe 1f+JrJysgdLx4x3q42w4SAkUAVvdC0b5mIskpVvcJBW1qMXcjlSVUGlzL3Yh0YhysYdag5GVNzD k3Y9WbyeB7gHksNAi3DUy2NWBKIZnLMziP6GK99FhZxjg0sRl6Pw4FGcL9ILT3Bo9in/PlTxJKh XW99MzC/IkFpx6NUQzf+6apdTDJiykqyuALCls5vHUhvOVHu9wVOjHKg/9ccv2Ea78awu+Z71Jt chZmnblA7c1DoUYTB3w=
X-Received: by 2002:a05:6820:5306:b0:68d:bb0e:9c97 with SMTP id 006d021491bc7-694615cd048mr188798eaf.7.1776364267756; Thu, 16 Apr 2026 11:31:07 -0700 (PDT)
MIME-Version: 1.0
References: <AS4PR07MB88250EF7936CDB2163D88C3089232@AS4PR07MB8825.eurprd07.prod.outlook.com>
In-Reply-To: <AS4PR07MB88250EF7936CDB2163D88C3089232@AS4PR07MB8825.eurprd07.prod.outlook.com>
From: Mike Ounsworth <ounsworth+ietf@gmail.com>
Date: Thu, 16 Apr 2026 13:30:55 -0500
X-Gm-Features: AQROBzAvzSesABmz0QlofuS__0GgRZRIXS7axdGHcOq30rh8stDrMmJ85qOVihc
Message-ID: <CAKZgXHon4Z5sOgZ=Rz74PTnK+eRGKmkrXd1kWjvYRbGSyKxYHg@mail.gmail.com>
To: John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002be164064f980970"
Message-ID-Hash: S4FOABOOCPJOKQYWO7ENQAHAX2PSVQET
X-Message-ID-Hash: S4FOABOOCPJOKQYWO7ENQAHAX2PSVQET
X-MailFrom: ounsworth@gmail.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 List <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/KIS6O3ZOIVL6KjnhdbRiBhIODlE>
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>

Hi TLS,

I don't often wade into this WG, but I've been summoned into this thread
due to the crazy amount of mis-understanding of composites on display here.

The argument that you have to manage two private keys and that leaks up and
down the crypto library and the application stack reeks of
misunderstanding. We specifically designed composites to be one algorithm
with one OID with one key. We even (at the strong request of the LAMPS WG)
picked one representation of the private keys of each component algorithm
(ex.: CRT for RSA, seeds for ML-DSA, etc) so that there is a single unique
encoding for each composite private key. If you are going to claim that
composites are complex, please at least use accurate information.

The reference implementation is about 40 lines of python per composite. All
composites are implemented in 1400 lines of python, and more that 50% of
that is the harness to generate and spit out the test vectors and all the
markdown tables for the draft.
https://github.com/lamps-wg/draft-composite-sigs/blob/main/src/generate_test_vectors.py
So please don't tell me that something that can be implemented in like 40
lines of python is the most complex crypto we've ever done (have you taken
a look at PLANTS recently? Can't do that in 40 lines of python... and yet,
for some reason, composites are "complex".)


As for applicability to TLS: to me, the value of composites in TLS is not
for server certs, but for CA certs, you know, the ones that get embedded in
cacerts files of devices that never receive a patch. Or go into a cardboard
box today and expect to be able to phone home securely when they come out
of that cardboard box maybe as much as 7 years later. Or even for EE certs
on devices that, I don't know, sit under the hood of your car for 20 years
chattering away by TLS waiting for an attacker to plug in an ethernet
cable. You know those wireless payment terminals that you tap your credit
card against? They use TLS. Guess how often restaurant staff apply firmware
updates to them? Approximately 0%.

I don't expect CA/B Forum to ever ballot for Composite ML-DSA roots.  Fine.
Great, even. That's not the use case that caused me to spend 6 years of my
life on this.
But rather, for the things that use TLS that are not Web and do not get the
luxury of assuming rapid CA rollover and regular client patching. Important
things, too. For many of those things, their PQ migration journey is going
to extent well into the 2030's or even 2040's -- the credit card makers
haven't even starting printing ML-DSA based credit cards yet; we're still
years away from _starting_ that journey, so we're not too late for
composites to be useful in those use cases.


After reading this thread, I am pondering requesting to do a talk at SAAG
in Vienna about what composites are, and what they are not, and where I see
them adding value, and where not.

On Thu, 16 Apr 2026 at 12:32, John Mattsson <john.mattsson=
40ericsson.com@dmarc.ietf.org> wrote:

> Hi,
>
> While I recommend everybody to use X25519MLKEM768, I do not think TLS
> should work on hybrid authentication. If hybrid authentication is
> nevertheless worked on, the composite signatures in
> draft-reddy-tls-composite-mldsa seem like the least suitable approach.
>
> Work on hybrid signatures in 2026 is a distraction delaying the urgent
> migration to PQC signatures, particularly for PKI and long-lived devices. I
> see little justification for placing less trust in ML-DSA than in RSA or
> ECDSA (EdDSA is a good algorithm but is not widely used in TLS). In fact,
> the sooner RSA and ECDSA can be replaced by ML-DSA or SLH-DSA, the better.
> For those not yet ready to adopt ML-DSA, standalone SLH-DSA is the way to
> go.
>
> All modern signature schemes (RSA-PSS, EdDSA, LMS, XMSS, ML-DSA, SLH-DSA,
> FN-DSA) avoid trivial attacks on strong unforgeability and provide a high
> level of SUF-CMA security. I do not think TLS should introduce any new weak
> signature algorithms such as draft-reddy-tls-composite-mldsa.
> draft-reddy-tls-composite-mldsa goes against the principle in both US SP
> 800-227 and EU Roadmap for transition to PQC which states that hybrids
> should preserve the security properties of its components. The new
> cryptographic algorithms in draft-reddy-tls-composite-mldsa (which has not
> been vetted by CFRG) significantly weakens the security properties of
> ML-DSA as they introduce trivial attacks on strong unforgeability.
>
> With the algorithms in draft-reddy-tls-composite-mldsa, a CA does not
> issue a single certificate; instead, it issues a set of valid certificates,
> each with its own fingerprint. This has practical consequences for TLS.
> Logging, SIEM, and threat intelligence systems often record events such as
> “Observed certificate fingerprint X connecting to service Y,” implicitly
> treating the fingerprint as a stable identifier. Similarly, blocklists
> often operate on fingerprints (e.g., “Block fingerprint X”), and incident
> response workflows often rely on fingerprints as unique identifiers when
> searching for the attacker across datasets. In the presence of trivial
> attacks on strong unforgeability, these assumptions break down, as the same
> underlying certificate can appear under many fingerprints. I think
> standardizing ECDSA with trivial attacks on strong unforgeability was a big
> mistake that should not be repeated.
>
> Cheers,
> John Preuß Mattsson
> _______________________________________________
> 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