| Internet-Draft | PQ-HSTS | October 2026 |
| Sheffer, et al. | Expires 2 May 2027 | [Page] |
This document defines an HTTP response header field, Require-PQ-Auth, that
instructs user agents to require a quantum-resistant certificate chain in
subsequent connections. This is a short-term, opt-in mechanism for HTTP
origins to protect against legacy classical trust anchors. It will become
unnecessary when UAs remove these trust anchors.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://yaronf.github.io/draft-sheffer-tls-pq-hsts/draft-sheffer-tls-pq-hsts.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sheffer-tls-pq-hsts/.¶
Discussion of this document takes place on the Transport Layer Security Working Group mailing list (mailto:tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Subscribe at https://www.ietf.org/mailman/listinfo/tls/.¶
Source for this draft and an issue tracker can be found at https://github.com/yaronf/draft-sheffer-tls-pq-hsts.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 2 May 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Migrating TLS authentication to post-quantum cryptography cannot be done by flipping a single switch. For a long period, many origins will still present classical certificate chains, so user agents (UAs) will need to trust classical trust anchors alongside quantum-resistant ones. This allows an attacker able to forge classical certificates to downgrade the connection. Whether or not the origin had actually upgraded, a client that still accepts classical paths will treat that forged credential as valid.¶
This document defines an HTTP response header field, Require-PQ-Auth,
which allows an origin to indicate to the user agent to only accept chains
from quantum-resistant trust anchors in subsequent connections.¶
This is a near-term mechanism with several limitations described in Section 7.3. It is intended to be temporary, for use until classical trust anchors are removed. [ChromiumPQAuthRoadmap] describes a fuller migration program in which an HSTS-like opt-in is only an early stage.¶
As additional context, deployments will use different quantum-resistant
credential forms, including Merkle Tree Certificates (MTC). Normative
requirements in this document stay at the trust-anchor abstraction so
those forms can satisfy Require-PQ-Auth without tying the pin to a
single encoding.¶
This document addresses classical trust-anchor impersonation during the dual-trust-store migration period. An attacker forges a classical certificate with a cryptographically-relevant quantum computer (CRQC) for a name whose operator intends to use only quantum-resistant authentication, and presents that credential to a dual-accepting UA. The negotiated key agreement does not matter for this attack: the holder of the forged credential can impersonate the server whether key agreement is classical or quantum-resistant.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
The following terms are used in this document:¶
Cryptography that is not designed to remain secure against a CRQC [RFC9958].¶
Cryptography that is designed to remain secure against a CRQC.¶
The root of acceptance for a certification path, as defined in [RFC5280].¶
A host for which the UA stores a Require-PQ-Auth policy
(Section 3, Section 5), including expiry derived from max-age
and whether include-subdomains applies. The UA obtains that policy by
noting the header field or by local policy (for example, a
preconfigured list).¶
Require-PQ-Auth is an HTTP Structured Header field [RFC9651]. Its
value MUST be a Dictionary. Unknown members MUST be ignored.¶
If the field value cannot be parsed as a Dictionary or does not include a
valid max-age member, the UA MUST NOT
update any Noted PQ Policy for the host based on that field (any
previously Noted policy remains unchanged). See
Section 2.2 of [RFC9651].¶
The following Dictionary members are defined.¶
Integer (required). Non-negative number of seconds after receipt during which the UA regards the host as a Known PQ Host with this policy. A value of 0 signals the UA to delete any Noted PQ Policy for the host (including subdomain scope learned from this host).¶
Boolean (optional). True if present as a bare Dictionary member. If
set, the PQ Policy applies to the host and to hosts whose domain
names are subdomains of that host's domain name, analogous to HSTS
includeSubDomains [RFC6797].
Absence means host-only scope.¶
Examples:¶
Require-PQ-Auth: max-age=86400 Require-PQ-Auth: max-age=31536000, include-subdomains¶
If the server sends a Require-PQ-Auth header, all servers that are
authoritative for the origin MUST, for at least the period denoted by max-age,
serve a certification path that meets Section 5.2 in response to TLS
connections from post-quantum-capable UAs. If the include-subdomains member
is true, all servers authoritative for any subdomain of the origin MUST also
meet this requirement.¶
A typical server deployment will need a combination of classical and post-quantum certification paths for all its supported UAs, including legacy ones that do not support quantum-resistant trust anchors. This header does not constrain connections from legacy UAs. Servers MAY continue to serve classical certification paths in those cases.¶
How legacy and post-quantum-capable UAs are determined is out of scope for this document. Section 4.5.1.2 of [RFC9846] describes the general framework for TLS certificate selection, but the exact criteria can be application-dependent, depending on the ClientHello fields sent by each UA, the trust anchors each UA trusts, etc.¶
The server MUST send Require-PQ-Auth only over HTTPS. If sent, it SHOULD
include the header on every HTTPS response.¶
max-age SHOULD reflect how long the operator is willing to keep the
commitment above. Operators typically start with a short max-age while
gaining confidence, then increase it.¶
include-subdomains MUST NOT be sent unless every host that would be
covered can likewise satisfy the commitment for the same window.¶
A valid Require-PQ-Auth field replaces any previously Noted PQ Policy
for that host when the UA notes it (Section 5). Omitting the header
does not clear Noted policy.¶
To delete client state before expiry, the server sends max-age with
value 0. UAs that successfully note that response MUST delete the Noted
PQ Policy (Section 5). However, this mechanism is limited. UAs with
the previous Noted policy will continue to enforce the policy until it is
cleared. A server that is no longer able to meet the commitment might be
unable to serve such UAs until the outstanding policies expire.¶
This section defines how UAs note and enforce Require-PQ-Auth policy.¶
Upon receipt of a valid Require-PQ-Auth header field in an HTTP response, the
UA notes a PQ Policy when all of the following hold, and MUST NOT note
one otherwise:¶
The response was received over an error-free HTTPS connection that uses TLS 1.3 [RFC9846] or later.¶
That connection meets the checks in Section 5.2.¶
When noting, the UA MUST:¶
Store a PQ Policy for the host as a Known PQ Host, with expiry derived
from max-age (or delete the policy if max-age is 0).¶
Store the value of the include-subdomains member.¶
If a subsequent valid Require-PQ-Auth field is noted for the host, it
replaces the prior PQ Policy (including the include-subdomains member) for
that host. Absence of the header field on a later response does not by itself
clear PQ Policy before expiry; servers clear state with max-age of 0.¶
Although this mechanism is similar to HSTS [RFC6797], Known PQ Hosts are
separate from Known HSTS Hosts, with separate values for max-age and
include-subdomains.¶
UAs MAY additionally configure other hosts as Known PQ Hosts via local policy. For example, the UA MAY be pre-configured with a list of pre-loaded Known PQ Hosts, similar to Section 12.3 of [RFC6797].¶
A connection meets the checks of this section when both of the following hold. These checks apply when noting a PQ Policy and when enforcing one.¶
The trust anchor that caused acceptance is quantum-resistant.¶
Every signature and public key on the accepted certification path is quantum-resistant.¶
Which trust anchors and algorithms count as quantum-resistant is a matter of local policy. The UA is presumed to maintain classical trust anchors alongside quantum-resistant ones during the dual-trust-store period. This document states the property, not a closed algorithm list.¶
When a UA establishes a connection to a host, it checks if either:¶
If either of these conditions hold, the connection MUST use TLS 1.3 [RFC9846] or later, and MUST meet the checks in Section 5.2.¶
If the connection does not meet those requirements, the UA MUST abort the TLS handshake with a fatal "handshake_failure" alert ([RFC9846], Section 6.2).¶
The UA MAY skip enforcement according to local policy. For example, similar to Section 2.6 of [RFC7469], the UA MAY skip enforcement if the validated certificate chain terminates at a user-defined trust anchor, rather than a trust anchor built into the UA (or underlying platform). The main use case is a middlebox that terminates TLS using such a locally installed trust anchor.¶
Once the UA has removed classical trust anchors, Require-PQ-Auth is redundant.
Such UAs MAY remove support for this mechanism and stop tracking Known PQ Hosts.
Once all supported UAs are at this stage, servers MAY stop sending this header.¶
The commitment in Section 4 applies to every authoritative server for
each covered name. Operators that use multiple CDNs, failover providers,
or HTTP/3 endpoints advertised via Alt-Svc [RFC7838] need each of them
to meet Section 5.2 toward UAs that enforce this mechanism, for the full
max-age window.¶
Require-PQ-Auth policy is independent of HSTS policy. Operators choose
max-age and include-subdomains for this header separately from
Strict-Transport-Security. Noting requires HTTPS (Section 5.1); the host
need not be a Known HSTS Host.¶
The security considerations of HSTS (Section 14 of [RFC6797]) apply
to Require-PQ-Auth. This section covers where they differ.¶
Quantum resistance for a TLS session also requires a quantum-resistant
key agreement mechanism. While Require-PQ-Auth does not directly
constrain the key agreement, the TLS handshake provides downgrade
protection when the authentication itself is secure
(Appendix F.1 of [RFC9846]). Provided the Known PQ Host's TLS server
is correctly configured to prefer quantum-resistant key agreement
methods, a CRQC cannot downgrade the TLS session to a classical key
agreement mechanism.¶
The authentication pin still mitigates the threat this document targets even if key agreement remains classical. Classical trust-anchor impersonation requires offline certificate forgery with a CRQC. Breaking a live classical Diffie-Hellman key agreement to recover session keys requires a real-time CRQC attack on that handshake. That is a harder, later capability than the dual-trust-store impersonation this pin blocks for Known PQ Hosts.¶
UAs that do not implement this document ignore the header field. If such a UA accepts both classical and quantum-resistant authentication, an attacker with a CRQC can present a forged classical certificate even when the server offers a quantum-resistant one.¶
As with HSTS, noting a PQ Policy does not protect initial visits to an origin.
An attacker who can modify that first response can strip Require-PQ-Auth,
and the UA never notes the policy. Additionally, UAs might limit state set by
an origin, as described in Section 8. When state is limited, there are more
"initial" responses for an attacker to intercept.¶
Section 5.1 permits UAs to configure other Known PQ Hosts as local policy, such as a pre-configured list. While such measures can mitigate this attack, they can introduce other limitations when the number of otherwise quantum-resistant hosts exceeds an implementation's size limits.¶
Non-browser clients may be further limited in their ability to both maintain state and include large, pre-configured lists.¶
These limitations mean Require-PQ-Auth is only viable as a temporary measure
for a limited number of applications. In many applications, it will still be
necessary to keep trusting classical trust anchors in the near term.
[ChromiumPQAuthRoadmap]
describes one such transition plan.¶
An attacker that controls a middlebox that terminates TLS can cause a UA
to note Require-PQ-Auth only when the connection meets Section 5.2. A
middlebox that cannot meet those checks cannot set the policy.¶
If the attacker can meet the checks and sets a large max-age, UAs that
note the policy require Section 5.2 until the policy expires.
include-subdomains extends that requirement to every covered name.
Sending max-age of 0 does not remove the policy unless some endpoint
the UA will accept can still meet Section 5.2 and deliver that value
(Section 4). If the attacker was the only such endpoint and then stops
meeting the checks, the origin stays unreachable until the policy
expires.¶
The mechanism described in Section 5.1 causes a UA to maintain state based on user activity in the UA. This state could be used to correlate user activity across contexts, such as across sites or between normal and private browsing profiles. [ProtectingAgainstHSTSAbuse] and [StrictNavigationalSecurity] discuss analogous issues for HSTS.¶
UAs SHOULD mitigate this by clearing Known PQ Hosts when the user clears other site-specific state, and by partitioning Known PQ Host state across sensitive contexts, such as across sites or across browsing profiles. Note that these mitigations will limit the effectiveness of this mechanism, as discussed in Section 7.3.¶
IANA is requested to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in Section 16.3.1 of [RFC9110]. The registration is:¶
RFC Editor: please remove before publication.¶
Initial version.¶
[I-D.sheffer-tls-pqc-continuity] defines a similar opt-in mechanism, but at the TLS layer, instead of the HTTP layer. This document adapts those ideas for the HTTP layer.¶