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
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
CC: "tls@ietf.org" <tls@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Composite_ML-DSA?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/dgtr2zMoHxiwasmgL1PvoR_oLuo>

--000000000000521f89064f871038
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM <tim.beckmann=3D40mailbox.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 device=
s
> 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 upwar=
ds
> of a year. With IoT, this can be because the devices are stored in a crat=
e
> 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 th=
at
> information. When they authenticate the backend many months later, for th=
e
> 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 endpoi=
nt
> 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 robu=
st
> 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 wit=
h
> 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
>


--=20

Sophie Schmieg | Information Security Engineer | ISE Crypto |
sschmieg@google.com

--000000000000521f89064f871038
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>hi all,</div><div><br></div><div>here is my dump on t=
houghts about hybrid signatures, apologizes if some of the points have alre=
ady been brought up before</div><div><br></div>When it comes to implementat=
ion security, I&#39;ve never fully bought the argument that hybrids pose a =
meaningful defense. The most dangerous implementation vulnerabilities are t=
hings like spectre, row hammer, or good old buffer overflows.=C2=A0Since me=
mory is shared, the vulnerability of a hybrid implementation to these issue=
s is the union of the risk surfaces of the individual implementation, so us=
ing 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 th=
e 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 fo=
r can be tests very well using high quality test vector suites like Wychepr=
oof (It was actually difficult to find compelling test cases for Wycheproof=
 due to the design decisions made in the spec which made many creative inpu=
t choices simply not work, as opposed to classical crypto where such creati=
ve choices result in fun vulnerabilities).<div><br></div><div>In my experie=
nce, by far the biggest risk when it comes to signatures is not in the algo=
rithms themselves, but implementers either forgetting to verify, ignoring t=
he verification result, or forgetting to check that the message actually at=
tests to the thing they wanted attesting for (i.e. the valid certificate fo=
r a different domain problem). If the hybrid is implemented as a single alg=
orithm, this risk doesn&#39;t differ between hybrid and non-hybrid signatur=
e (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 signatu=
res, you add code that is a frighteningly close Hamming distance away from =
code that ignores all signatures.=C2=A0If 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).</div><div><=
br></div><div>In many cases, signature keys can be revoked with varying amo=
unts of pain. In those circumstances, the additional security benefit of hy=
brids 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 g=
rabs), this is good enough in most threat models, and as such I don&#39;t c=
onsider hybrid signatures essential in those use cases. When they can be do=
ne without additional cost (this cost can be in terms of performance, overh=
ead or even coordination headwinds), I still recommend using hybrid signatu=
res, but with a heavy bias towards just using pure signatures in case of di=
fficulties arising. Most importantly for the IETF here are the coordination=
 difficulties. I much prefer having pure ML-DSA over not having any PQC sig=
nature at all.</div><div><br></div><div>There are cases where revocation is=
 not really possible, like for example firmware signing keys. Here I much p=
refer having SLH-DSA, or as a fallback, hybrid signatures, but these usuall=
y do not require fully standardized solutions for the hybrid construction.<=
br><div><br></div><div><div>[1]=C2=A0<a href=3D"https://eprint.iacr.org/202=
4/523">https://eprint.iacr.org/2024/523</a></div></div></div></div><br><div=
 class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmai=
l_attr">On Wed, Apr 15, 2026 at 1:27=E2=80=AFPM &lt;tim.beckmann=3D<a href=
=3D"mailto:40mailbox.org@dmarc.ietf.org">40mailbox.org@dmarc.ietf.org</a>&g=
t; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u=
>

=20
 =20
=20
 <div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">Hi,</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">I&#39;d like to add a perspective on why hybrid certificates and au=
thentication are useful. My background is with IoT and OT (operational tech=
nology) devices manufactured by medium-sized businesses. These devices ofte=
n maintain a connection to the manufacturer&#39;s backend, mutually authent=
icated by small scale private PKIs (plural, because device certificates and=
 backend certificates are under different roots).</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">The deployment of these devices has the unfortunate property that b=
etween 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 kee=
p devices in storage for hot swapping in case of hardware failures for any =
of the deployed devices.</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">The transition from traditional to post-quantum authentication meth=
ods poses a significant problem for these device classes. In many other sce=
narios, you can flip the switch from ECDSA-based authentication to ML-DSA-b=
ased authentication the moment you judge the CRQC threat as too high by pus=
hing a config or software/firmware update. (This requires that PQ-keys/-cer=
tificates have been distributed beforehand, of course.) But devices lying i=
n storage have no active internet connection to receive that information. W=
hen 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&#39;m=
 still somewhat on the fence about that in regard to targets that don&#39;t=
 have extremely high value.)</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">One way around that dilemma is to do an initial check on whether au=
thentication should be switched over, by connecting to a special endpoint o=
nce with ECDSA certificates and once with ML-DSA certificates and verify th=
at both give the same advice (and abort if they don&#39;t). But from an ope=
rational perspective, issuing hybrid certificates as soon as possible and j=
ust using those for mutual TLS seems to be the easiest and most robust solu=
tion.</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">(Now, there are a lot of hurdles along the way. Most notably, secur=
e elements (and cellular modems with TLS stacks) are still widely missing M=
L-DSA support (or SLH-DSA for that matter), but we have that problem with n=
on-composites as well.)</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">What are your thoughts on that? Do you know of a more straightforwa=
rd solution? Relying only on ML-DSA as soon as possible is problematic, bot=
h because of customer concern and regulatory requirements.</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">=C2=A0</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">Best regards,</div>
  <div style=3D"font-family:-apple-system,BlinkMacSystemFont,helvetica,sans=
-serif">Tim Beckmann</div>
 </div>
_______________________________________________<br>
TLS mailing list -- <a href=3D"mailto:tls@ietf.org" target=3D"_blank">tls@i=
etf.org</a><br>
To unsubscribe send an email to <a href=3D"mailto:tls-leave@ietf.org" targe=
t=3D"_blank">tls-leave@ietf.org</a><br>
</blockquote></div><div><br clear=3D"all"></div><div><br></div><span class=
=3D"gmail_signature_prefix">-- </span><br><div dir=3D"ltr" class=3D"gmail_s=
ignature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div><div dir=3D"ltr"><div=
><div dir=3D"ltr"><div><div dir=3D"ltr"><div style=3D"line-height:1.5em;pad=
ding-top:10px;margin-top:10px;color:rgb(85,85,85);font-family:sans-serif;fo=
nt-size:small"><span style=3D"border-width:2px 0px 0px;border-style:solid;b=
order-color:rgb(213,15,37);padding-top:2px;margin-top:2px"><br>Sophie Schmi=
eg=C2=A0|</span><span style=3D"border-width:2px 0px 0px;border-style:solid;=
border-color:rgb(51,105,232);padding-top:2px;margin-top:2px">=C2=A0Informat=
ion Security Engineer=C2=A0|</span><span style=3D"border-width:2px 0px 0px;=
border-style:solid;border-color:rgb(0,153,57);padding-top:2px;margin-top:2p=
x">=C2=A0ISE Crypto=C2=A0|</span><span style=3D"border-width:2px 0px 0px;bo=
rder-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2p=
x">=C2=A0<a href=3D"mailto:sschmieg@google.com" target=3D"_blank">sschmieg@=
google.com</a></span></div><div><span style=3D"border-width:2px 0px 0px;bor=
der-style:solid;border-color:rgb(238,178,17);padding-top:2px;margin-top:2px=
"><br></span></div><span style=3D"color:rgb(0,0,0);font-family:&quot;Times =
New Roman&quot;;font-size:medium"></span></div></div></div></div></div></di=
v></div></div></div></div>

--000000000000521f89064f871038--