]> Independent

yaronf.ietf@gmail.com

Nokia

kondtir@gmail.com

Google LLC

davidben@google.com

Security Transport Layer Security post-quantum migration HSTS Structured Fields 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Transport Layer Security Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction 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 . It is intended to be temporary, for use until classical trust anchors are removed. 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.

Threat Model 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.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. The following terms are used in this document:

classical:

Cryptography that is not designed to remain secure against a CRQC .

quantum-resistant:

Cryptography that is designed to remain secure against a CRQC.

trust anchor:

The root of acceptance for a certification path, as defined in .

Known PQ Host / PQ Policy:

A host for which the UA stores a Require-PQ-Auth policy (, ), 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).

Syntax Require-PQ-Auth is an HTTP Structured Header field . 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 . The following Dictionary members are defined.

max-age:

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

include-subdomains:

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 . Absence means host-only scope.

Examples:

Server Processing 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 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. 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.

Choosing Policy Parameters 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.

Updating and Clearing Policy A valid Require-PQ-Auth field replaces any previously Noted PQ Policy for that host when the UA notes it (). 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 (). 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.

User Agent Behavior This section defines how UAs note and enforce Require-PQ-Auth policy.

Noting the Header 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:

1. The response was received over an error-free HTTPS connection that uses TLS 1.3 or later.
2. That connection meets the checks in .

When noting, the UA MUST:

1. 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).
2. 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 , 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 .

Quantum-Resistant Paths 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.

1. The trust anchor that caused acceptance is quantum-resistant.
2. 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.

Enforcement When a UA establishes a connection to a host, it checks if either:

• the host is a Known PQ Host
• the host is a subdomain of a Known PQ Host with include-subdomains

If either of these conditions hold, the connection MUST use TLS 1.3 or later, and MUST meet the checks in . If the connection does not meet those requirements, the UA MUST abort the TLS handshake with a fatal "handshake_failure" alert (, Section 6.2). The UA MAY skip enforcement according to local policy. For example, similar to , 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.

Operational Considerations The commitment in applies to every authoritative server for each covered name. Operators that use multiple CDNs, failover providers, or HTTP/3 endpoints advertised via Alt-Svc need each of them to meet 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 (); the host need not be a Known HSTS Host.

Security Considerations The security considerations of HSTS () apply to Require-PQ-Auth. This section covers where they differ.

Key Agreement 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 (). 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.

Non-Conformant User Agent Implications 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.

Limitations 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 . When state is limited, there are more "initial" responses for an attacker to intercept. 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. describes one such transition plan.

Denial of Service An attacker that controls a middlebox that terminates TLS can cause a UA to note Require-PQ-Auth only when the connection meets . 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 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 and deliver that value (). If the attacker was the only such endpoint and then stops meeting the checks, the origin stays unreachable until the policy expires.

Privacy Considerations The mechanism described in 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. and 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 .

IANA Considerations IANA is requested to register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" defined in . The registration is:

Field name:

Require-PQ-Auth

Status:

permanent

Structured Type:

Dictionary

Specification document(s):

this document; see

Comments:

Defined for the header section of HTTP responses. Not defined for use as a trailer field.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers". It is intended for use by specifications of new HTTP fields. This document obsoletes RFC 8941. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. This document also specifies new requirements for TLS 1.2 implementations. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Informative References The advent of a cryptographically relevant quantum computer (CRQC) would render state-of-the-art, traditional public key algorithms deployed today obsolete, as the mathematical assumptions underpinning their security would no longer hold. To address this, protocols and infrastructure must transition to post-quantum algorithms, which are designed to resist both traditional and quantum attacks. This document explains why engineers need to be aware of and understand post-quantum cryptography (PQC), and it details the impact of CRQCs on existing systems and the challenges involved in transitioning to post-quantum algorithms. Unlike previous cryptographic updates, this shift may require significant protocol redesign due to the unique properties of post-quantum algorithms. This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example. [STANDARDS-TRACK] This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities. This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration. Intuit Nokia As the Internet transitions toward post-quantum cryptography (PQC), many TLS servers will continue supporting traditional certificates to maintain compatibility with legacy clients. However, this coexistence introduces a significant vulnerability: an undetected rollback attack, where a malicious actor strips the PQC or composite certificate and forces the use of a classical certificate once quantum-capable adversaries exist. To defend against this, this document defines a TLS extension that allows a TLS client to cache a server's declared commitment to present PQC or composite certificates for a specified duration. On subsequent connections, the client enforces that cached commitment and rejects traditional-only certificates that conflict with it. This mechanism, inspired by HTTP Strict Transport Security (HSTS) but operating at the TLS layer, provides PQC downgrade protection without requiring changes to certificate authority (CA) infrastructure.

Document History RFC Editor: please remove before publication.

draft-sheffer-tls-pq-hsts-00 Initial version.

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