Subject: [TLS] Re: Composite ML-DSA
From: Sophie Schmieg <[email-masked]>
To: tim.beckmann=[email-masked]
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 15 Apr 2026 15:16:01 -0700
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.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=[email-masked]>
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 -- [email-masked]
> To unsubscribe send an email to [email-masked]
>

-- 

Sophie Schmieg | Information Security Engineer | ISE Crypto |
[email-masked]