For SSH signatures, keep the classical layer

A call for adoption, and a bigger question

The IETF Secure Shell Maintenance working group is running a call for adoption that closes on 17 August 2026, with the stated goal of taking on two documents at once: one covering pure ML-DSA signatures and one covering ML-DSA plus elliptic-curve hybrids. Post-quantum key exchange already ships in SSH. Signatures, the host keys and the public keys that authenticate users, are the next piece. The narrow question is which drafts to adopt. The larger question, and the one the group should answer first, is whether SSH has any business standardizing a solo post-quantum signature for authentication at all. On the record so far, the more careful answer is no.

Cheap insurance against a young primitive

The strongest case comes from D. J. Bernstein, and it does not rest only on the familiar worry that the lattice math might one day be broken. His sharper argument is about software. In a talk titled "The impact of post-quantum bugs," using Dilithium (ML-DSA) as a case study, he presented a graph estimating "the number of ML-DSA-44 keys that will be breakable each year simply because of the predictable flood of exploitable software vulnerabilities." Implementations of a new, complicated primitive will have CVEs, and some of those CVEs will leak keys. That is not a hypothetical about future quantum computers. It is the ordinary history of cryptographic code.

The remedy is nearly free. "We'll see many more ML-DSA CVEs; keeping an ECC layer will often save the day and has very low cost," Bernstein wrote. A composite Ed25519 plus ML-DSA key forces an attacker to defeat both halves, so a bug in the lattice code alone does not open the door. He argues the comparison holds up better than the marketing does: "the comparison of Ed25519+ML-DSA-44 to solo ML-DSA-44 is robust," even as the underlying bug-rate numbers move. And he is blunt about the stakes if the specification itself is flawed rather than merely the code: "The security damage of allowing solo PQ rather than ECC+PQ will be even worse than shown in the graph if there are exploitable flaws in the PQ spec."

Bernstein has long rejected the idea that cryptanalysis is a rare event operators can discount. "Certainly there are endless examples of crypto being bypassed. However, the quotes below indicate that crypto is often attacked. What exactly is your basis for claiming otherwise?" he asked earlier in the debate, citing documented programs aimed at breaking deployed encryption. For host keys and user keys that persist for years in known_hosts files, certificates, and hardware tokens, betting the entire authentication decision on a single primitive introduced only a few years ago is a large wager to make when a classical hedge costs so little.

"Signatures are short-lived" is the wrong comfort

The main technical counter is that authentication signatures do not need decades of security. Watson Ladd put it directly: "Signatures do not need to survive beyond the lifetime of an authentication which is very short." That holds for the confidentiality of a session, but it misreads the threat to authentication. A host key or user key that can be forged is a live credential now. If a software bug makes solo ML-DSA keys forgeable, an attacker impersonates the server or the user at connection time, and the short lifetime of any single signature offers no protection. Bugs do not wait for a cryptographically relevant quantum computer, which is precisely why the ECC layer earns its keep in the present tense.

A coalition, not a lone objector

This is not one person against a settled consensus. Simon Josefsson, responding to the proposal to adopt a pure ML-DSA draft as a working group item, was just as clear: "I'm against that -- and would like that we adopt hybrid signature schemes, or a more conservative PQ signature scheme like SLH-DSA." He offered an off-ramp for those who still want solo post-quantum: "If people want to pursue non-hybrid PQ it is fine to do IANA registration and, if an RFC is desired, do a ISE submission. That would avoid repeating the TLS WG drama." He also questioned the authority to adopt it at all: "I'm not certain the SSHM WG charter covers adopting a work item like the one above." Concrete hybrid drafts already exist to build on, among them draft-sun-ssh-composite-sigs and Damien Miller's mldsa65-ed25519 and mldsa44-ed25519 composite drafts.

The other side is not unreasonable, and deserves to be stated plainly. Scott Fluhrer, an author of a pure ML-DSA draft, supports hybrids as an addition rather than a replacement, saying he would back a hybrid draft "as long as you do 'in addition to' rather than 'instead of'." Ryan Appel argued that the existence of a hybrid case does not veto a pure one: "I have no issue with the argument that hybrid should exist, but I do not believe that that argument is valid to state pure should not exist." Pure ML-DSA is simpler to specify, has fewer parameters to negotiate, and is already written down in draft-sfluhrer-ssh-mldsa and draft-rpe-ssh-mldsa. Even Filippo Valsorda, sympathetic to composites, located their biggest practical benefit not in cryptographic hedging but in hardware, bridging "the gap to ML-DSA hardware" while tokens catch up.

Those are real advantages. They are also arguments for letting a solo option exist somewhere, such as the independent stream Josefsson pointed to, not for the maintenance working group blessing solo ML-DSA as a default path for SSH authentication before the objections have been answered.

Process is part of the security argument

That brings up how this call for adoption arrived. The chairs told the list that "This week the WG agreed to do a call for adoption for PQ sigs using ECC and ML-DSA with the initial goal being to adopt ONE draft covering hybrids and ONE covering pure ML-DSA." Bernstein could not find that agreement in the archives and asked a simple question: did the "WG agreed" claim refer to an in-person meeting rather than the list? He noted the IETF's own statement that official working-group work is conducted on the list, and pointed to a meeting poll that asked only "do people think taking on the ssh sig work is a reasonable thing?", drawing 22 yes, 2 no, and 6 no-opinion answers from 56 people present. Broad interest in doing signature work is not the same as a decision to adopt a solo ML-DSA draft.

"People who could afford to attend the meeting don't have more rights under IETF rules than other interested parties," he wrote. "It's wrong for the chairs to state the decisions of those people as WG decisions." And: "It's not acceptable to mislead list participants into thinking that decisions were made already." He also asked, citing RFC 2418's requirement that disagreements "must be resolved by a process of open review and discussion," why his April objections to pure ML-DSA had gone unanswered on the list.

Chair Stephen Farrell was dismissive. "Your interpretations of IETF processes are IMO generally wildly wrong;-)" he replied, declining to "debug general IETF process issues here," warning that repetitive posting could be moderated, and cautioning that, as with a recent TLS effort he described as astroturfed, newcomers arriving only for this call would be discounted. Guarding a call for adoption against manufactured support is legitimate. So is answering, on the list, whether a contested choice was quietly presented as settled. Framing the call around "one pure and one hybrid," as if the pure half were already decided, puts a thumb on the scale of the very consensus the call is supposed to measure.

The prudent default

The working group does not have to declare ML-DSA untrustworthy to make the safe choice. It only has to notice that a classical layer costs little and removes an entire class of failure, that bugs are certain even when the math holds, and that authentication forgeries are a present danger rather than a future one. Adopt the hybrids. Let solo ML-DSA prove itself through the independent stream if its proponents want it. And settle the question in the open, on the list, before the 17 August deadline turns a contested proposal into a standard.