IETF Logo Mail Archive

[TLS] Re: Composite ML-DSA

Sophie Schmieg <sschmieg@google.com> Wed, 15 April 2026 22:16 UTC

Return-Path: <sschmieg@google.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 71F2CDD310F9 for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 15:16:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1776291381; bh=V/0ZHrBBM5rGDOTSOXPrVGCjCbSYM/soirTHmrp3aWg=; h=References:In-Reply-To:From:Date:Subject:To:Cc; b=LFIVni1zVguJHUBI2o0VWhx15sPyNdbdisSpmazcznneVT4FJcZxeqhNiLe8gURsv iQH3XWT53yPxytWcdEdBP5gE158Bpfnxs3ImzMw/HLtnhuUvPzrfAQRm/mruMn+bEK VgDPs6Nn8yyH0FckPd+rLx05PrZYXH8likPezjzY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -17.6
X-Spam-Level:
X-Spam-Status: No, score=-17.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 OqP-FEA9d8Dh for <tls@mail2.ietf.org>; Wed, 15 Apr 2026 15:16:20 -0700 (PDT)
Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) (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 BD2B9DD310F2 for <tls@ietf.org>; Wed, 15 Apr 2026 15:16:20 -0700 (PDT)
Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-488879dcbc3so12245e9.0 for <tls@ietf.org>; Wed, 15 Apr 2026 15:16:20 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1776291374; cv=none; d=google.com; s=arc-20240605; b=Xrbw7o4DmznfIkrLVzT4ewTmGO17aV2Ei8QUzEKjc6eLGi/aJq00LSN6/dSIDB52LI 40mnc7m38I0oDqd7D1Tp3gs31WzVmhe855qMSZgPJi+mYLL3SBUFOh9pkDUXZkd1Qwg4 JdU3RQpZW+absAHlFMA7Gl1ixKlChi0C+j80SIWZrNg/51JtPMOAoNxCXRIs/OYsF7Ek BDG+vhdbAKqk/dmUVd/XdHOreihr0JcR4AbanGrE07HnbWOMGeTHX/yjdp58uo0N8nPb YWS1O35XZyeHg3Fodl7tEAvWjeZClzzPCsb+iZzWy63051bleoWIBDA3qutGimnYILwl rJ+Q==
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=OLtFyOZl3wI5rYXTT+RYID5xaZ3obgXyLd5+BuUA0y8=; fh=8NcakiwU3MteJbimJVuynkviKf3JG/irk/zE54FEwJg=; b=fna2atApm24pZLIZIGhi+/sMIqDR2bq8DYtIuy/MlYRBpo5S5sjMcexdiHwOqvzOpD VHiSy9/+1LRdbSc6hSUHS3Ec3TJGlSyOO7XuQfEwvGJHooy0DNVcHH3yDOZgh0VWlI4v wSast5akTw4cdvVg8CYrGRP2T/Z0lK2LX4gfDzIn9mhZv12O9SM36r0ZI9YbFEe66AhR LMc91HsUWZ1sIvTikxdXL/duIlIfqr2kAnNktl7krEtTkmNzat8CUSV5IK9OFbtOPdbg xiRsoXqvUSxJerf/2F0ozir2KT6F2/+r0Uemz9/JRfyJKECWJdJFEvsG1+UW2tBW08Lc Xhiw==; darn=ietf.org
ARC-Authentication-Results: i=1; mx.google.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1776291374; x=1776896174; 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=OLtFyOZl3wI5rYXTT+RYID5xaZ3obgXyLd5+BuUA0y8=; b=JB5M1HxiDAmyF0Fve8xK4jQUMgDEohorWySwENA8+OW0Xs/GEExjbFjOdmP+JN5fl9 K/jXRa+q+KrEnYSbmDOR6qF9aWFctQfV7SwKQsHXYnvC0cNgiMQ789B3Ur74klZlFtcr 0c+QFERjI2pYiRZhTYovfriXAXjJwuEnIT6lQ9F1n+ZECtzET3KzlZlBrfDkpb6p1+cq 6Ai5uqp4kXEgb2sHLf/tbGGCCBJB0DiTaLk7p26tiP8wRONXRIEHWy/pE8s1XwJNeG0f Yq7XJSGtEHfg6viOuJotOEKqi16jLwUU7lI2WPB5Yis4zNkVYKHBPAzr9/1GpNaLrxHF 1mwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1776291374; x=1776896174; 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=OLtFyOZl3wI5rYXTT+RYID5xaZ3obgXyLd5+BuUA0y8=; b=Phm/eeM9T4L9MBiOxnE0/oK5TfXI07h1h+2jQ8fTtALKZEsfkuaah7cwqNucXJI0C+ VaUK8rv2bzhgB+UlzUI3R1XOER5PwJgtvLV82VwNcG2a7EQhYfo9WgjPlX/7RZabbdFj CUPLSLFP78nYRTBJ9kMksdhn6WdwDsFuFAuJCRGdUqTUjtEc1Sraq6HbK0NEi3hdkAAv hBT/Y0fk6KwQCgHvYQxn99fdGb4wRTfpI+KpeVF3IqkBGBSMh+R0kLP6G7iz+SHYK+ji eaHfS+296A6KG1DO5AzPM53lpvZjdDrax7iWiLJzBho0TasreEHdbM2/5+bZx6c5R4J6 TKiA==
X-Gm-Message-State: AOJu0YwMRVMAeE8+tVvexHvNXv1McrlgFV3QQM+1VcobZE7YHGsWlKBm FlFw0vwhs/3OXQvMtS5je/DsEbIRQESNFj4Dqx+MZ//vKameCTwgQSDaD8pI/BlxzVrBUgWWA6V hd4fF7fR3r0l7r2Aw0LXm6qIcE7guvLKAREFCBhkBY/Zz+/hmG0mKobdWYHU=
X-Gm-Gg: AeBDieuF077Xx/T3rPlG1jFpVxJlKgVUp8Iv14o/cjcZX6S2yiv1jrcdqtItYNJyvmK sBP5TgKIdFEFihU8yaxVZ1h7iz6AX4Zakbk3GzMSOVn0D+mqSwSAsrOvOeKTYlY888oyh9BmBq7 t3Cyx3Lcrm5n3USFPw7YuzVU49/XH/5gkm0I3AsSd94y/xzz7x1UQ1LedIMa0ubMq5mI+e0ur+n Ens66CTZzdyZEDfZ0bQzP5TNiaYYqZF87pAK/4VsxVZfvcT1Cy/HFvsTGZUYy8dwnvzlpiSm0Ih BWHnC1C0B2Q/6TRZIolG/xN1vET+Ege2PAle/KzH4dAiMtMamGa29ksi+lxtudcdj6Jxurm8mfS YoSztDSUCeF98q2I=
X-Received: by 2002:a05:600d:c:b0:485:b6e4:9808 with SMTP id 5b1f17b1804b1-488f5110da2mr137095e9.1.1776291373216; Wed, 15 Apr 2026 15:16:13 -0700 (PDT)
MIME-Version: 1.0
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> <129715714.1963.1776284832509@app.mailbox.org>
In-Reply-To: <129715714.1963.1776284832509@app.mailbox.org>
From: Sophie Schmieg <sschmieg@google.com>
Date: Wed, 15 Apr 2026 15:16:01 -0700
X-Gm-Features: AQROBzBt5Jm-heUcwCEB3X_XVY0v1YW0sqkLThvo7iALkRXBGaI8fsWnjuA83a0
Message-ID: <CAEEbLAYbQF5XapVPqGbNCuj64oYiYQ5BO5WnRBeXFQuFzs=o8g@mail.gmail.com>
To: tim.beckmann=40mailbox.org@dmarc.ietf.org
Content-Type: multipart/alternative; boundary="000000000000521f89064f871038"
Message-ID-Hash: OIAHXYDWAGNJWYITWRQ2ZWRSUC3OVBCQ
X-Message-ID-Hash: OIAHXYDWAGNJWYITWRQ2ZWRSUC3OVBCQ
X-MailFrom: sschmieg@google.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/dgtr2zMoHxiwasmgL1PvoR_oLuo>
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 all,

here is my dump on thoughts about hybrid signatures, apologizes if some of
the points have already been brought up before

When it comes to implementation security, I've never fully bought the
argument that hybrids pose a meaningful defense. The most dangerous
implementation vulnerabilities are things like spectre, row hammer, or good
old buffer overflows. Since memory is shared, the vulnerability of a hybrid
implementation to these issues is the union of the risk surfaces of the
individual implementation, so using a hybrid increases the risks. You could
argue that correctness related vulnerabilities like CRT faults or point not
on curve attacks are the main implementation mistakes hybrids protect
against, but given the design of the PQC algorithms which do not allow for
many subtle logic bugs (at least as long as one uses seeds as private keys
[1]), and the bugs they do allow for can be tests very well using high
quality test vector suites like Wycheproof (It was actually difficult to
find compelling test cases for Wycheproof due to the design decisions made
in the spec which made many creative input choices simply not work, as
opposed to classical crypto where such creative choices result in fun
vulnerabilities).

In my experience, by far the biggest risk when it comes to signatures is
not in the algorithms themselves, but implementers either forgetting to
verify, ignoring the verification result, or forgetting to check that the
message actually attests to the thing they wanted attesting for (i.e. the
valid certificate for a different domain problem). If the hybrid is
implemented as a single algorithm, this risk doesn't differ between hybrid
and non-hybrid signature (and this is one of the reasons why I strongly
prefer this approach). The more details of the hybrid construction is
exposed to the caller, the more this is no longer the case. If you teach a
verifier to ignore some signatures, you add code that is a frighteningly
close Hamming distance away from code that ignores all signatures. If you
want to do things like using an HSM for your classical signature, but a
software implementation for your PQC signature, the only takeaway that I
can see is to bury this capability as deep in the cryptographic library as
possible, and not expose any of it to the caller (other than possibly a
boolean flag that enables the HSM or a classical software implementation,
but even that is dubious).

In many cases, signature keys can be revoked with varying amounts of pain.
In those circumstances, the additional security benefit of hybrids is soley
in defense against unpublished attacks, as published attacks will be
mitigated via revocation. As the blast radius for signatures has a strict
end with revocation of the key (as opposed to encryption, where any
ciphertext that has ever been encrypted with the algorithm is now up for
grabs), this is good enough in most threat models, and as such I don't
consider hybrid signatures essential in those use cases. When they can be
done without additional cost (this cost can be in terms of performance,
overhead or even coordination headwinds), I still recommend using hybrid
signatures, but with a heavy bias towards just using pure signatures in
case of difficulties arising. Most importantly for the IETF here are the
coordination difficulties. I much prefer having pure ML-DSA over not having
any PQC signature at all.

There are cases where revocation is not really possible, like for example
firmware signing keys. Here I much prefer having SLH-DSA, or as a fallback,
hybrid signatures, but these usually do not require fully standardized
solutions for the hybrid construction.

[1] https://eprint.iacr.org/2024/523

On Wed, Apr 15, 2026 at 1:27 PM <tim.beckmann=40mailbox.org@dmarc.ietf.org>
wrote:

> Hi,
>
> I'd like to add a perspective on why hybrid certificates and
> authentication are useful. My background is with IoT and OT (operational
> technology) devices manufactured by medium-sized businesses. These devices
> often maintain a connection to the manufacturer's backend, mutually
> authenticated by small scale private PKIs (plural, because device
> certificates and backend certificates are under different roots).
>
> The deployment of these devices has the unfortunate property that between
> production and first installation a lot of time can pass, sometimes upwards
> of a year. With IoT, this can be because the devices are stored in a crate
> or a shelf somewhere along the retail chain, with OT, operators keep
> devices in storage for hot swapping in case of hardware failures for any of
> the deployed devices.
>
> The transition from traditional to post-quantum authentication methods
> poses a significant problem for these device classes. In many other
> scenarios, you can flip the switch from ECDSA-based authentication to
> ML-DSA-based authentication the moment you judge the CRQC threat as too
> high by pushing a config or software/firmware update. (This requires that
> PQ-keys/-certificates have been distributed beforehand, of course.) But
> devices lying in storage have no active internet connection to receive that
> information. When they authenticate the backend many months later, for the
> first time in over a year, the ECDSA keys might have been compromised
> already. (Under the assumption that attacks against EC keys are widely
> available soon. I'm still somewhat on the fence about that in regard to
> targets that don't have extremely high value.)
>
> One way around that dilemma is to do an initial check on whether
> authentication should be switched over, by connecting to a special endpoint
> once with ECDSA certificates and once with ML-DSA certificates and verify
> that both give the same advice (and abort if they don't). But from an
> operational perspective, issuing hybrid certificates as soon as possible
> and just using those for mutual TLS seems to be the easiest and most robust
> solution.
>
> (Now, there are a lot of hurdles along the way. Most notably, secure
> elements (and cellular modems with TLS stacks) are still widely missing
> ML-DSA support (or SLH-DSA for that matter), but we have that problem with
> non-composites as well.)
>
> What are your thoughts on that? Do you know of a more straightforward
> solution? Relying only on ML-DSA as soon as possible is problematic, both
> because of customer concern and regulatory requirements.
>
> Best regards,
> Tim Beckmann
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>


-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschmieg@google.com

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