Skip to content

SYSTEM Cited by 1 source

PQ HSTS

What

PQ HSTS (Post-Quantum HTTP Strict Transport Security) is a browser-side downgrade-protection mechanism for the post-quantum authentication transition: once a site has advertised PQ signature support, the browser refuses to accept classical signatures from that origin going forward — analogous to how classical HSTS makes browsers refuse HTTP after observing HTTPS support on an origin.

Being developed as part of Chromium's post-quantum auth roadmap. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

The problem it solves

Post-Q-Day, an attacker with a CRQC can forge classical TLS signatures. If browsers accept either classical or PQ signatures (needed during transition to not break old origins), an active attacker can:

  1. Strip PQ support from the server's advertised algorithms.
  2. Force the handshake to select a classical signature.
  3. Forge that classical signature (CRQC-enabled).
  4. MITM the connection.

This is the downgrade attack specific to the PQ transition. Transcript binding doesn't save you — the transcript signature itself is forgeable.

For closed systems the answer is simple: disable classical signatures entirely. For the open web, this is infeasible because many origins won't migrate to PQ on any reasonable timeline, and browsers need to keep working with them. PQ HSTS is the best-of-both-worlds design: "on sites where you have seen PQ signatures, require them from now on."

How it works (high level)

Similar to classical HSTS but for PQ-signature support:

1. Browser connects to origin; server advertises PQ signature
   algorithms + sends a PQ-HSTS header (or preload-list entry).
2. Browser stores: "this origin supports PQ authentication;
   refuse classical signatures from it, effective for N days /
   includeSubDomains".
3. On subsequent connections to that origin, browser rejects
   the handshake if classical signatures are the only option.
4. If the origin stops advertising PQ HSTS, the commitment
   expires after the declared max-age.

The HSTS model is well-understood: preload lists for bootstrap (first-visit protection via pre-shipped lists), TOFU (trust-on-first-use) for dynamic sites, max-age for expiration, includeSubDomains for sub-origin coverage, operational incident-recovery procedures for "we accidentally broke our own origin."

Design constraints

  • Do not break non-migrated origins. Browsers must continue to work with origins that haven't deployed PQ; PQ HSTS applies only to origins that have opted in by advertising PQ support.
  • Rollback discipline. If an origin enables PQ HSTS and later needs to roll back, max-age lets the commitment expire naturally. Too-long max-age creates operational risk.
  • Preload list curation. High-traffic origins (banks, search, major SaaS) need preload-list inclusion so first-visit protection works; this creates a curation burden similar to classical HSTS preload.
  • Interaction with CT — PQ HSTS pairs with CT-based downgrade detection: if CT logs show PQ certs exist for an origin but the handshake doesn't offer them, that's detectable as an attack regardless of PQ-HSTS status.

Relationship to the broader PQ rollout

Cloudflare's 2026 PQ post names PQ HSTS explicitly as the feasible answer to the disablement problem for federated systems:

Disabling quantum-vulnerable cryptography is not the last step: once done, all secrets such as passwords and access tokens previously exposed in the quantum-vulnerable system need to be rotated. [...] downgrade protection for HTTPS is still achievable using "PQ HSTS" and/or certificate transparency. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

The pattern is disable legacy before rotate; PQ HSTS is the mechanism that makes disablement-by-origin-cohort tractable for the browser ecosystem.

Raw-scope caveats

This wiki page is scoped to what the Cloudflare 2026 post names:

  • PQ HSTS exists as a proposed mechanism.
  • Cloudflare names it as one of the "achievable" downgrade- protection options for HTTPS.
  • Chromium's post-quantum auth roadmap is cited as the venue.

Specific protocol details — exact header syntax, max-age semantics, preload-list governance, interaction with DoH / ECH, revocation escape hatches — are not in the Cloudflare post; they are covered in the Chromium roadmap document and future IETF draft work.

Seen in

Last updated · 200 distilled / 1,178 read