]> Apple Inc.

One Apple Park Way Cupertino, California 95014 United States of America tpauly@apple.com

Cloudflare

caw@heapingbits.net

Security Privacy Pass token extensions This document describes an in-band key consistency enforcement mechanism for Privacy Pass deployments wherein the Attester is split from the Issuer and Origin. About This Document Status information for this document may be found at . Discussion of this document takes place on the Privacy Pass Working Group mailing list (), which is archived at . Subscribe at .

Introduction Key and configuration consistency is an important preqrequisite for guaranteeing security properties of Privacy Pass. In particular, privacy informally depends on Clients using an Issuer key that many, if not all, other Clients use. If a Client were to receive an Issuer key that was specific to them, or restricted to a small set of Clients, then use of that Issuer key could be used to learn targeted information about the Client. Clients that share the same Issuer key are said to have a consisten key. describes general patterns for implementing consistency in protocols such as Privacy Pass, and describes a protocol-agnostic mechanism for implementing consistency checks that can apply to Privacy Pass. K-Check is an orthogonal protocol for checking consistency of a given key that runs out-of-band of Privacy Pass. This document specifies an in-band consistency check for Privacy Pass. It is only applicable to deployments where the Attester is split from the Origin and Issuer. This is because the Attester is responsible for enforcing consistency on behalf of many Clients.

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.

Attester Consistency Check In Privacy Pass deployment models where the Attester is split from the Origin and Issuer, Clients interact with the Attester to run the issuance protocol for obtaining tokens. In particular, Clients obtain tokens from the Issuer by sending token requests to the Attester, which forwards token requests to the Issuer. As an active, on-path participant in the issuance protocol, the Attester is capable of applying enforcement checks for these token requests. This section describes a simple key consistency enforcement check to ensure that all Clients behind the Attester share a consistent view of the Issuer key. Upon receipt of a token request, which contains a key ID as described in , an Attester does the following:

1. The Attester checks that it has a cached copy of the private token directory from the Issuer corresponding to the token request. If the Attester does not, it first obtains a copy of the directory. If this fails, the Attester aborts the token request with a failure.
2. The Attester compares the key ID corresponding in the token request to the the valid keys in the directory. If no match is found, the Attester aborts token request with a failure.
3. If the above steps succeed, the Attester allows the token request to proceed.

Attesters can update their cached copy of Issuer token directories independently of token requests. Attesters SHOULD refresh their cached copy of the Issuer directory when it becomes invalid (according to cache control headers). Attesters SHOULD enforce that Issuer directories contain few keys suitable for use at any given point in time, and penalize or reject Issuers that advertise too many keys. This is because Clients and Origins may choose different keys from this directory based on their local state, e.g., their clock, and too many keys could be misused for the purposes of partitioning Client anonymity sets.

Security Considerations Unlike K-Check, in which Clients can check key consistency against the first valid key in an Issuer private token directory, the Attester consistency check in this document needs to allow for greater flexibility, in particular because Client diversity and differences may lead to different key selections. Attesters need to balance this flexibility against the overall privacy goals of this consistency check. Admitting an unbounded number of keys in the Issuer's directory effectively renders the consistency check meaningless, as each Client could be given a unique key that belongs to the directory set.

IANA Considerations This document has no IANA actions.

References Normative References LIP Fastly Cloudflare This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for constructing privacy-preserving authentication mechanisms. It provides recommendations on how the architecture should be deployed to ensure the privacy of clients and the security of all participating entities. Brave Software Brave Software Google LLC Cloudflare This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the issuance private key, and another that produces tokens that are publicly verifiable using the issuance public key. Brave Software The Tor Project Mozilla Cloudflare This document describes the consistency requirements of protocols such as Privacy Pass, Oblivious DoH, and Oblivious HTTP for user privacy. It presents definitions for consistency and then surveys mechanisms for providing consistency in varying threat models. In concludes with discussion of open problems in this area. Mozilla Cloudflare This document describes a system for forwarding encrypted HTTP messages. This allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. 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. Informative References

Acknowledgments This document was the product of the consistency design team in the Privacy Pass working group.