Abstract

This piece analyzes the active on-path adversary of the post-quantum threat model: one that strips the post-quantum protection from a dual-stack system to leave it on breakable classical cryptography, requiring no quantum computer at all. It distinguishes the in-band downgrade — tampering with algorithm negotiation, which authenticated negotiation such as TLS 1.3's transcript hashing detects — from the more insidious out-of-band fallback trap, where the attacker simply blocks the post-quantum attempt so the client retries with classical-only, mistaking the interference for a network problem. It explains why a successful downgrade directly re-enables harvest-now-decrypt-later by removing the post-quantum component of a hybrid exchange, and lays out the defenses: authenticated negotiation, fallback-signaling sentinels, and fail-closed post-quantum-required policies for at-risk data. It closes with the agent-mesh angle. The theme: downgrade protection is about authenticating the negotiation and refusing insecure fallback, because an attacker who cannot break the cryptography can still trick a system into not using it.

The active adversary in a post-quantum threat model has a deceptively simple goal: make sure the post-quantum cryptography is never used. It needs no quantum computer — it exploits the transitional reality that a migrating system supports both classical and post-quantum schemes, and it works to keep victims on the classical one it can eventually break. This downgrade can be attempted in-band, by tampering with algorithm negotiation, or out-of-band, by simply blocking the post-quantum attempt so the system falls back on its own. Understanding both, and why a successful downgrade re-arms the harvest-now-decrypt-later threat, is essential to defending a dual-stack migration.

In-band downgrade, and why negotiation binding stops it

The direct downgrade is to tamper with the negotiation. In a handshake where the parties advertise supported algorithms and agree on a common one, an on-path attacker could try to edit the advertised lists or the selection so that both sides settle on classical-only cryptography, believing it was the best mutual option. If this tampering went undetected, the attacker would have silently stripped the post-quantum protection while both endpoints thought they had negotiated honestly.

Modern protocols defend against this with authenticated negotiation. In a well-designed handshake the entire negotiation transcript — the advertised options and the final selection — is folded into the session's integrity check, so any tampering causes the two sides' computed transcripts to differ and the handshake to fail. The final authentication step, computed over the whole transcript, will not verify if an attacker altered the advertised groups, so an in-band downgrade is detected rather than silently accepted. This is the same transcript-binding that the migration articles credited with preventing a silent group downgrade.

The lesson is that downgrade protection is fundamentally about authenticating the negotiation: if the outcome of the negotiation is cryptographically bound into the session, an attacker cannot rewrite it undetected. But this protection covers only in-band tampering with a negotiation that actually completes. It does nothing about an attacker who prevents the post-quantum negotiation from happening at all, which is the more insidious route the next section describes.

Authenticated negotiation detects in-band tampering; but blocking the attempt entirely evades it, looking like an ordinary network failure. In-band tampering versus out-of-band denial In-band tamperalters negotiation Transcript detectsfinal MAC fails Out-of-band denyblock the attempt Fallback undetectedlooks like network
Authenticated negotiation detects in-band tampering; but blocking the attempt entirely evades it, looking like an ordinary network failure.

The fallback trap

The dangerous downgrade does not tamper with negotiation; it prevents it. Many clients, for compatibility, are configured to try the post-quantum option first and fall back to classical if it fails — a sensible-seeming policy given the middlebox and size problems that can make a large post-quantum handshake fail on some paths. An attacker exploits exactly this: it blocks or corrupts the post-quantum attempt, perhaps by dropping the large handshake packets, so the client concludes there is a network problem and retries with classical-only cryptography, which the attacker allows through.

The insidiousness is that nothing looks wrong. The client's fallback logic worked as designed; the connection succeeded; no tampering was detected because none occurred in-band. The attacker never touched a negotiation transcript — it induced the victim to downgrade itself by manipulating the network conditions the fallback policy responds to. This is a denial-of-service against the post-quantum path that converts, through the fallback policy, into a silent downgrade, and it defeats the transcript-binding defense entirely because the transcript that gets bound is the classical one the client freely chose.

This is the crux of downgrade defense in a dual-stack migration: the very fallback that provides compatibility is the vulnerability. A policy of trying post-quantum and quietly reverting to classical on failure hands an active attacker a reliable downgrade, because the attacker can always manufacture the failure. The problem is not the negotiation's authentication but the client's willingness to accept a classical outcome when the post-quantum one is obstructed.

The attacker blocks the post-quantum attempt so the client's fallback policy retries with classical-only, downgrading itself without any detectable tampering. The fallback trap Client offers hybridlarge ClientHello Attacker blocks itdrops the packets Client retriesclassical only Silently downgradedHNDL re-exposed
The attacker blocks the post-quantum attempt so the client's fallback policy retries with classical-only, downgrading itself without any detectable tampering.

Why a downgrade re-arms harvest-now-decrypt-later

A successful downgrade is not a minor loss of a security margin; it directly re-enables the anchor threat. The hybrid exchange's whole value was that it stayed secure if either the classical or the post-quantum component survived, protecting confidentiality against the future quantum attacker. Stripping the exchange to classical-only removes the post-quantum component entirely, so the session's confidentiality now rests solely on the classical scheme — exactly the scheme the harvest-now-decrypt-later collector is betting a future quantum computer will break.

So the active downgrade attacker and the passive harvesting attacker are complementary. The passive collector records traffic hoping it is classically protected; the active downgrader ensures that it is, by forcing sessions back to classical-only. Together they close the loop: the downgrade makes the harvest fruitful. A migration that deployed hybrid protection but permits silent downgrade has, against a capable adversary, not migrated its confidentiality at all for the sessions the attacker chooses to downgrade.

This connection is why downgrade resistance is not a secondary concern but a first-order requirement of protecting long-lived confidential data. Migrating to hybrid cryptography and then allowing an attacker to strip the post-quantum half leaves the at-risk data exactly as exposed as before. The threat model must treat the downgrade path as a direct route to the harvest-now-decrypt-later harm it was trying to prevent.

Defending the negotiation

Three layers of defense address downgrade. The first is authenticated negotiation, already described: binding the negotiation transcript into the session so in-band tampering is detected. This is table stakes and is provided by modern protocols, but it does not stop the fallback trap. The second is fallback signaling: a mechanism by which a client that has fallen back indicates that it did so, allowing a server that supports the better option to recognize the fallback as anomalous and refuse it — the same idea as the sentinel signals introduced historically to stop version-rollback attacks. This closes the gap the fallback trap exploits by making an induced fallback detectable.

The third and most decisive is policy: for data that must be post-quantum protected, do not silently fall back to classical at all. A fail-closed, post-quantum-required mode refuses to complete a connection that cannot use the post-quantum path, so an attacker who blocks it causes a visible connection failure rather than a silent downgrade. This trades availability for security — a blocked post-quantum path becomes an outage rather than an exposure — which is the right trade for high-value, long-lived, at-risk data, even if not for every connection. At minimum, an induced fallback for such data should raise an alert rather than pass silently.

The choice among these is itself a threat-model decision. Low-stakes, short-lived traffic can accept graceful fallback for compatibility; high-stakes, long-lived confidential traffic — the harvest-now-decrypt-later targets — should fail closed or alert, because for that data a downgrade is a genuine compromise. Matching the fallback policy to the asset's shelf-life and stakes, rather than applying one blanket policy, is how a migration keeps compatibility where it can afford it and security where it must have it.

Authenticated negotiation stops in-band tampering, fallback signaling exposes induced fallback, and a fail-closed post-quantum-required policy protects at-risk data. Downgrade defenses Downgrade defenseslayered Authenticated negotiationtranscript bound Fallback signalingexpose induced fallback Fail closedPQ-required for at-risk
Authenticated negotiation stops in-band tampering, fallback signaling exposes induced fallback, and a fail-closed post-quantum-required policy protects at-risk data.

The playbook, and the agent mesh

The defensive playbook follows from the layers. Ensure the protocol authenticates its negotiation so in-band downgrade is detected. Deploy fallback signaling so an induced classical fallback is recognized and can be refused. And set a fail-closed, post-quantum-required policy for the data classified as at-risk in the harvest-now-decrypt-later inventory, accepting that a blocked post-quantum path for that data should be an outage or an alert rather than a silent reversion to breakable cryptography. Monitor for downgrade patterns — spikes in classical fallback on paths that should support post-quantum — as an indicator of an active attacker.

Rollback has a signature-side analogue worth noting: an attacker might present classical-only certificates or force classical signature verification to keep a system on breakable authentication, and the same principles apply — authenticate the negotiation of signature algorithms and, for critical trust decisions, refuse to accept a downgrade to classical-only. The general rule is that any place a system can be steered to a weaker option is a downgrade surface to authenticate and, for high-value cases, to fail closed on.

For autonomous AI systems the downgrade threat lands on the dual-stack agent and model channels. An attacker on the path of an agent service mesh can block the post-quantum handshake between services so they fall back to classical, silently re-exposing model and agent traffic to the passive collector — precisely the traffic whose long-lived confidentiality the migration was meant to protect. The guidance is to run agent-to-service and model-endpoint channels in a fail-closed post-quantum-required mode for at-risk data, deploy fallback signaling across the mesh, and monitor for anomalous classical fallback, so that an attacker who cannot break the agents' cryptography cannot trick them out of using it either. Downgrade resistance is the control that keeps the hybrid migration from being quietly undone.

⚠️
Fallback is the vulnerability. An attacker who blocks the post-quantum attempt makes a silent-fallback client downgrade itself, re-exposing data to harvest-now-decrypt-later with no detectable tampering. For at-risk data, fail closed on a post-quantum-required policy rather than reverting to classical.

Key takeaways

  • The active downgrade attacker needs no quantum computer; it strips the post-quantum protection from a dual-stack system to leave it on breakable classical cryptography.
  • In-band downgrade — tampering with algorithm negotiation — is detected by authenticated negotiation (transcript binding), but this covers only a negotiation that completes.
  • The fallback trap is more dangerous: the attacker blocks the post-quantum attempt so a silent-fallback client retries classical-only, downgrading itself with no detectable tampering.
  • A successful downgrade directly re-arms harvest-now-decrypt-later by removing the post-quantum component, so the passive collector and active downgrader are complementary.
  • Defenses layer: authenticated negotiation for in-band tampering, fallback signaling to expose induced fallback, and a fail-closed post-quantum-required policy (or at least an alert) for at-risk data.
  • Match fallback policy to shelf-life and stakes; for AI agent and model channels carrying at-risk data, fail closed, deploy fallback signaling across the mesh, and monitor for anomalous classical fallback.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

Assessing downgrade resistancechecklist

Check that a dual-stack deployment resists being stripped.

  • Is the algorithm negotiation authenticated (transcript bound into the session)?
  • Is fallback signaling deployed so an induced classical fallback is detectable?
  • Is there a fail-closed post-quantum-required mode for at-risk data?
  • Is anomalous classical fallback monitored as an attack indicator?
  • Is the fallback policy matched to each asset's shelf-life and stakes?
🚀Harden against downgradequickstart

Close the fallback trap for at-risk traffic.

  • Confirm authenticated negotiation is in place.
  • Enable fallback signaling across the deployment.
  • Set fail-closed post-quantum-required for high-value, long-lived data.
  • Monitor for classical-fallback spikes on post-quantum-capable paths.
🔒Downgrade-resistance policypolicy

A stub setting fallback behavior by asset risk.

downgrade_resistance:
  negotiation: authenticated_transcript_bound
  fallback_signaling: enabled
  at_risk_data:
    policy: fail_closed_pq_required
  low_stakes_data:
    policy: graceful_fallback_allowed
  monitoring: alert_on_classical_fallback_spike
agent_mesh:
  channels: pq_required_for_at_risk
Illustrative documentation template, not a product config.

Glossary

Downgrade attack
Forcing a dual-stack system onto weaker classical cryptography it still supports, without breaking the stronger option.
In-band downgrade
Tampering with the algorithm negotiation itself; detected by authenticated negotiation that binds the transcript into the session.
Fallback trap
Blocking the post-quantum attempt so a silent-fallback client retries classical-only, achieving a downgrade with no detectable in-band tampering.
Authenticated negotiation
Binding the negotiation transcript into the session's integrity so tampering causes the handshake to fail.
Fallback signaling
A client indication that it has fallen back, letting a capable server recognize and refuse an induced downgrade — like historical rollback sentinels.
Fail-closed / PQ-required
A policy that refuses to complete a connection lacking the post-quantum path, turning a blocked attempt into a visible failure rather than a silent downgrade.

References

  1. IETF draft-ietf-tls-hybrid-design, Hybrid Key Exchange in TLS 1.3
  2. NIST IR 8547, Transition to Post-Quantum Cryptography Standards (2024)
  3. Shostack, Threat Modeling: Designing for Security (Wiley, 2014)
  4. NIST SP 1800-38, Migration to Post-Quantum Cryptography (practice guide)
  5. Mosca, Cybersecurity in an Era with Quantum Computers (IEEE Security & Privacy, 2018)