[TLS] Re: Composite ML-DSA

[Dennis Jackson <[e-mail]>]

I broadly agree with Sophie, especially:

> 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).

I see hybrid KEX sticking around for a while, but I don't think 
composite signatures make much sense in any eventuality and especially 
if you think the probability of near-term CRQG is rising.

Best,
Dennis

On 15/04/2026 23:16, Sophie Schmieg wrote:
> 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=[e-mail]> 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 -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
>
> -- 
>
> Sophie Schmieg | Information Security Engineer | ISE 
> Crypto |[e-mail]
>
>
> _______________________________________________
> TLS mailing list [e-mail]
> To unsubscribe send an email [e-mail]