diff options
Diffstat (limited to 'doc/rfc/rfc9576.txt')
| -rw-r--r-- | doc/rfc/rfc9576.txt | 1375 |
1 files changed, 1375 insertions, 0 deletions
diff --git a/doc/rfc/rfc9576.txt b/doc/rfc/rfc9576.txt new file mode 100644 index 0000000..d99f1be --- /dev/null +++ b/doc/rfc/rfc9576.txt @@ -0,0 +1,1375 @@ + + + + +Internet Engineering Task Force (IETF) A. Davidson +Request for Comments: 9576 NOVA LINCS, Universidade NOVA de Lisboa +Category: Informational J. Iyengar +ISSN: 2070-1721 Fastly + C. A. Wood + Cloudflare + June 2024 + + + The Privacy Pass Architecture + +Abstract + + This document specifies the Privacy Pass architecture and + requirements for its constituent protocols used for authorization + based on privacy-preserving authentication mechanisms. It describes + the conceptual model of Privacy Pass and its protocols, its security + and privacy goals, practical deployment models, and recommendations + for each deployment model, to help ensure that the desired security + and privacy goals are fulfilled. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9576. + +Copyright Notice + + Copyright (c) 2024 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. + +Table of Contents + + 1. Introduction + 2. Terminology + 3. Architecture + 3.1. Overview + 3.2. Use Cases + 3.3. Privacy Goals and Threat Model + 3.4. Redemption Protocol + 3.5. Issuance Protocol + 3.5.1. Attester Role + 3.5.2. Issuer Role + 3.5.3. Issuance Metadata + 3.5.4. Future Issuance Protocol Requirements + 3.6. Information Flow + 3.6.1. Token Challenge Flow + 3.6.2. Attestation Flow + 3.6.3. Issuance Flow + 3.6.4. Token Redemption Flow + 4. Deployment Models + 4.1. Shared Origin, Attester, Issuer + 4.2. Joint Attester and Issuer + 4.3. Joint Origin and Issuer + 4.4. Split Origin, Attester, Issuer + 5. Deployment Considerations + 5.1. Discriminatory Treatment + 5.2. Centralization + 6. Privacy Considerations + 6.1. Partitioning by Issuance Metadata + 6.2. Partitioning by Issuance Consistency + 6.3. Partitioning by Side Channels + 7. Security Considerations + 7.1. Token Caching + 8. IANA Considerations + 9. References + 9.1. Normative References + 9.2. Informative References + Acknowledgements + Authors' Addresses + +1. Introduction + + Privacy Pass is an architecture for authorization based on privacy- + preserving authentication mechanisms. In other words, relying + parties authenticate Clients in a privacy-preserving way, i.e., + without learning any unique, per-Client information through the + authentication protocol, and then make authorization decisions on the + basis of that authentication succeeding or failing. Possible + authorization decisions might be to provide Clients with read access + to a particular resource or write access to a particular resource. + + Typical approaches for authorizing Clients, such as through the use + of long-term state (cookies), are not privacy friendly, since they + allow servers to track Clients across sessions and interactions. + Privacy Pass takes a different approach: instead of presenting + linkable state-carrying information to servers, e.g., a cookie + indicating whether or not the Client is an authorized user or has + completed some prior challenge, Clients present unlinkable proofs + that attest to this information. These proofs, or tokens, are + private in the sense that a given token cannot be linked to the + protocol interaction where that token was initially issued. + + At a high level, the Privacy Pass architecture consists of two + protocols: redemption and issuance. The redemption protocol, + described in [AUTHSCHEME], runs between Clients and Origins + (servers). It allows Origins to challenge Clients to present tokens + for consumption. Origins verify the token to authenticate the Client + -- without learning any specific information about the Client -- and + then make an authorization decision on the basis of the token + verifying successfully or not. Depending on the type of token, e.g., + whether or not it can be cached, the Client either presents a + previously obtained token or invokes an issuance protocol, e.g., the + protocols described in [ISSUANCE], to acquire a token to present as + authorization. + + This document describes requirements for both redemption and issuance + protocols and how they interact. It also provides recommendations on + how the architecture should be deployed to ensure the privacy of + Clients and the security of all participating entities. + +2. Terminology + + 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 throughout this document: + + Client: An entity that seeks authorization to an Origin. Using + terminology from [RFC9334], Clients implement the Remote + ATtestation procedureS (RATS) Attester role. + + Token: A cryptographic authentication message used for authorization + decisions, produced as output from an issuance mechanism or + protocol. + + Origin: An entity that consumes tokens presented by Clients and uses + them to make authorization decisions. + + Token challenge: The mechanism by which Origins request tokens from + Clients, often denoted TokenChallenge. + + Token request: A message used by Clients to request a token from an + Issuer, often denoted TokenRequest. + + Token response: A message used by Issuers to send tokens to a + Client, often denoted TokenResponse. + + Redemption: The mechanism by which Clients present tokens to Origins + for the purposes of authorization. + + Issuer: An entity that issues tokens to Clients for properties + attested to by the Attester. + + Issuance: The mechanism by which an Issuer produces tokens for + Clients. + + Attester: An entity that attests to properties of Clients for the + purposes of token issuance. Using terminology from [RFC9334], + Attesters implement the RATS Verifier role. + + Attestation procedure: The procedure by which an Attester determines + whether or not a Client has the specific set of properties that + are necessary for token issuance. + + The trust relationships between each of the entities in this list are + further elaborated upon in Section 3.3. + +3. Architecture + + The Privacy Pass architecture consists of four logical entities -- + Client, Origin, Issuer, and Attester -- that work in concert for + token redemption and issuance. This section presents an overview of + Privacy Pass, a high-level description of the threat model and + privacy goals of the architecture, and the goals and requirements of + the redemption and issuance protocols. Deployment variations for the + Origin, Issuer, and Attester in this architecture, including + considerations for implementing these entities, are further discussed + in Section 4. + +3.1. Overview + + This section describes the typical interaction flow for Privacy Pass, + as shown in Figure 1. + + 1. A Client interacts with an Origin by sending a request or + otherwise interacting with the Origin in a way that triggers a + response containing a token challenge. The token challenge + indicates a specific Issuer to use. + + 2. If the Client already has a token available that satisfies the + token challenge, e.g., because the Client has a cache of + previously issued tokens, it can skip to step 6 and redeem its + token; see Section 7.1 for security considerations regarding + cached tokens. + + 3. If the Client does not have a token available and decides it + wants to obtain one (or more) bound to the token challenge, it + then invokes the issuance protocol. As a prerequisite to the + issuance protocol, the Client runs the deployment-specific + attestation process that is required for the designated Issuer. + Client attestation can be done via proof of solving a CAPTCHA, + checking device or hardware attestation validity, etc.; see + Section 3.5.1 for more details. + + 4. If the attestation process completes successfully, the Client + creates a token request to send to the designated Issuer + (generally via the Attester, though it is not required to be sent + through the Attester). The Attester and Issuer might be + functions on the same server, depending on the deployment model + (see Section 4). Depending on the attestation process, it is + possible for attestation to run alongside the issuance protocol, + e.g., where Clients send necessary attestation information to the + Attester along with their token request. If the attestation + process fails, the Client receives an error and issuance aborts + without a token. + + 5. The Issuer generates a token response based on the token request, + which is returned to the Client (generally via the Attester). + Upon receiving the token response, the Client computes a token + from the token challenge and token response. This token can be + validated by anyone with the per-Issuer key but cannot be linked + to the content of the token request or token response. + + 6. If the Client has a token, it includes it in a subsequent request + to the Origin, as authorization. This token is sent only once in + reaction to a challenge; Clients do not send tokens more than + once, even if they receive duplicate or redundant challenges. + The Origin validates that the token was generated by the expected + Issuer and has not already been redeemed for the corresponding + token challenge. If the Client does not have a token, perhaps + because issuance failed, the Client does not reply to the + Origin's challenge with a new request. + + +--------+ +--------+ +----------+ +--------+ + | Origin | | Client | | Attester | | Issuer | + +---+----+ +---+----+ +----+-----+ +---+----+ + | | | | + |<----- Request ------+ | | + +-- TokenChallenge -->| | | + | |<== Attestation ==>| | + | | | | + | +--------- TokenRequest ------->| + | |<-------- TokenResponse -------+ + |<-- Request+Token ---+ | | + | | | | + + Figure 1: Privacy Pass Redemption and Issuance Protocol Interaction + +3.2. Use Cases + + Use cases for Privacy Pass are broad and depend greatly on the + deployment model as discussed in Section 4. The initial motivating + use case for Privacy Pass [PrivacyPassCloudflare] was to help rate- + limit malicious or otherwise abusive traffic from services such as + Tor [DMS2004]. The generalized and evolved architecture described in + this document also works for this use case. However, for added + clarity, some more possible use cases are described below. + + * Low-quality, anti-fraud signal for open Internet services. Tokens + can attest that the Client behind the user agent is likely not a + bot attempting to perform some form of automated attack such as + credential stuffing. Example attestation procedures for this use + case might be solving some form of CAPTCHA or presenting evidence + of a valid, unlocked device in good standing. + + * Privacy-preserving authentication for proprietary services. + Tokens can attest that the Client is a valid subscriber for a + proprietary service, such as a deployment of Oblivious HTTP + [OHTTP]. + +3.3. Privacy Goals and Threat Model + + The end-to-end flow for Privacy Pass described in Section 3.1 + involves three different types of contexts: + + Redemption context: The interactions and set of information shared + between the Client and Origin, i.e., the information that is + provided or otherwise available to the Origin during redemption + that might be used to identify a Client and construct a token + challenge. This context includes all information associated with + redemption, such as the timestamp of the event, Client-visible + information (including the IP address), and the Origin name. + + Issuance context: The interactions and set of information shared + between the Client, Attester, and Issuer, i.e., the information + that is provided or otherwise available to the Attester and Issuer + during issuance that might be used to identify a Client. This + context includes all information associated with issuance, such as + the timestamp of the event, any Client-visible information + (including the IP address), and the Origin name (if revealed + during issuance). This does not include the token challenge in + its entirety, as that is kept secret from the Issuer during the + issuance protocol. + + Attestation context: The interactions and set of information shared + between the Client and Attester only, for the purposes of + attesting the validity of the Client, that is provided or + otherwise available during attestation that might be used to + identify the Client. This context includes all information + associated with attestation, such as the timestamp of the event + and any Client-visible information, including information needed + for the attestation procedure to complete. + + The privacy goals of Privacy Pass assume a threat model in which + Origins trust specific Issuers to produce tokens, and Issuers in turn + trust one or more Attesters to correctly run the attestation + procedure with Clients. This arrangement ensures that tokens that + validate for a given Issuer were only issued to a Client that + successfully completed attestation with an Attester that the Issuer + trusts. Moreover, this arrangement means that if an Origin accepts + tokens issued by an Issuer that trusts multiple Attesters, then a + Client can use any one of these Attesters to issue and redeem tokens + for the Origin. Whether or not these different entities in the + architecture collude for learning redemption, issuance, or + attestation contexts, as well as the necessary preconditions for + context unlinkability, depends on the deployment model; see Section 4 + for more details. + + The mechanisms for establishing trust between each entity in this + arrangement are deployment specific. For example, in settings where + Clients interact with Issuers through an Attester, Attesters and + Issuers might use mutually authenticated TLS to authenticate one + another. In settings where Clients do not communicate with Issuers + through an Attester, the Attesters might convey this trust via a + digital signature that Issuers can verify. + + Clients explicitly trust Attesters to perform attestation correctly + and in a way that does not violate their privacy. In particular, + this means that Attesters that may be privy to private information + about Clients are trusted to not disclose this information to non- + colluding parties. Colluding parties are assumed to have access to + the same information; see Section 4 for more about different + deployment models and non-collusion assumptions. However, Clients + assume that Issuers and Origins are malicious. + + Given this threat model, the privacy goals of Privacy Pass are + oriented around unlinkability based on redemption, issuance, and + attestation contexts, as described below. + + 1. Origin-Client unlinkability. This means that given two + redemption contexts, the Origin cannot determine if both + redemption contexts correspond to the same Client or two + different Clients. Informally, this means that a Client in a + redemption context is indistinguishable from any other Client + that might use the same redemption context. The set of Clients + that share the same redemption context is referred to as a + redemption anonymity set. + + 2. Issuer-Client unlinkability. This is similar to Origin-Client + unlinkability in that a Client in an issuance context is + indistinguishable from any other Client that might use the same + issuance context. The set of Clients that share the same + issuance context is referred to as an issuance anonymity set. + + 3. Attester-Origin unlinkability. This is similar to Origin-Client + and Issuer-Client unlinkability. It means that given two + attestation contexts, the Attester cannot determine if both + contexts correspond to the same Origin or two different Origins. + The set of Origins that share the same attestation context is + referred to as an attestation anonymity set. + + 4. Redemption context unlinkability. Given two redemption contexts, + the Origin cannot determine which issuance and attestation + contexts each redemption corresponds to, even with the + collaboration of the Issuer and Attester (should these be + different parties). This means that any information that may be + learned about the Client during the issuance and attestation + flows cannot be used by the Origin to compromise Client privacy. + + These unlinkability properties ensure that only the Clients are able + to correlate information that might be used to identify them with + activity on the Origin. The Attester, Issuer, and Origin only + receive the information necessary to perform their respective + functions. + + The manner in which these unlinkability properties are achieved + depends on the deployment model, type of attestation, and issuance + protocol details. For example, as discussed in Section 4, in some + cases it is necessary to use an anonymization service that hides + Client IP addresses, such as Tor [DMS2004]. In general, + anonymization services ensure that all Clients that use the service + are indistinguishable from one another, though in practice there may + be small distinguishing features (TLS fingerprints, HTTP headers, + etc.). Moreover, Clients generally trust these services to not + disclose private Client information (such as IP addresses) to + untrusted parties. Failure to use an anonymization service when + interacting with Attesters, Issuers, or Origins can allow the set of + possible Clients to be partitioned by the Client's IP address and can + therefore lead to unlinkability violations. Similarly, malicious + Origins may attempt to link two redemption contexts together by using + Client-specific Issuer Public Keys. See Sections 5 and 6 for more + information. + + Sections 3.4 and 3.5 describe the functional properties and security + requirements of the redemption and issuance protocols in more detail. + Section 3.6 describes how information flows between the Issuer, + Origin, Client, and Attester through these protocols. + +3.4. Redemption Protocol + + The Privacy Pass redemption protocol, described in [AUTHSCHEME], is + an authorization protocol wherein Clients present tokens to Origins + for authorization. Normally, redemption is preceded by a challenge, + wherein the Origin challenges Clients for a token with a + TokenChallenge ([AUTHSCHEME], Section 2.1) and, if possible, Clients + present a valid token ([AUTHSCHEME], Section 2.2) in reaction to the + challenge. This interaction is shown below. + + +--------+ +--------+ + | Origin | | Client | + +---+----+ +---+----+ + | | + |<----- Request ------+ + +-- TokenChallenge -->| + | | <== Issuance protocol ==> + |<-- Request+Token ---+ + | | + + Figure 2: Challenge and Redemption Protocol Interaction + + Alternatively, when configured to do so, Clients may + opportunistically present token values to Origins without a + corresponding TokenChallenge. + + The structure and semantics of the TokenChallenge and token messages + depend on the issuance protocol and token type being used; see + [AUTHSCHEME] for more information. + + The challenge provides the Client with the information necessary to + obtain tokens that the server might subsequently accept in the + redemption context. There are a number of ways in which the token + may vary based on this challenge, including the following: + + * Issuance protocol. The challenge identifies the type of issuance + protocol required for producing the token. Different issuance + protocols have different security properties, e.g., some issuance + protocols may produce tokens that are publicly verifiable, whereas + others may not have this property. + + * Issuer identity. Token challenges identify which Issuers are + trusted for a given issuance protocol. As described in + Section 3.3, the choice of Issuer determines the type of Attesters + and attestation procedures possible for a token from the specified + Issuer, but the Origin does not learn exactly which Attester was + used for a given token issuance event. + + * Redemption context. Challenges can be bound to a given redemption + context, which influences a Client's ability to pre-fetch and + cache tokens. For example, an empty redemption context always + allows tokens to be issued and redeemed non-interactively, whereas + a fresh and random redemption context means that the redeemed + token must be issued only after the Client receives the challenge. + See Section 2.1.1 of [AUTHSCHEME] for more details. + + * Per-Origin or cross-Origin. Challenges can be constrained to the + Origin for which the challenge originated (referred to as per- + Origin tokens) or can be used across multiple Origins (referred to + as cross-Origin tokens). The set of Origins for which a cross- + Origin token is applicable is referred to as the cross-Origin set. + Opting into this set is done by explicitly agreeing on the + contents of the set. Every Origin in a cross-Origin set, by + opting in, agrees to admit tokens for any other Origin in the set. + See Section 2.1.1 of [AUTHSCHEME] for more information on how this + set is created. + + Origins that admit cross-Origin tokens bear some risk of allowing + tokens issued for one Origin to be spent in an interaction with + another Origin. In particular, cross-Origin tokens issued based on a + challenge for one Origin can be redeemed at another Origin in the + cross-Origin set, which can make it difficult to regulate token + consumption. Depending on the use case, Origins may need to maintain + state to track redeemed tokens. For example, Origins that accept + cross-Origin tokens across shared redemption contexts SHOULD track + which tokens have already been redeemed in those redemption contexts, + since these tokens can be issued and then spent multiple times for + any such challenge. Note that Clients that redeem the same token to + multiple Origins do risk those Origins being able to link Client + activity together, which can disincentivize this behavior. See + Section 2.1.1 of [AUTHSCHEME] for discussion. + + How Clients respond to token challenges can have privacy + implications. For example, if an Origin allows the Client to choose + an Issuer, then the choice of Issuer can reveal information about the + Client used to partition anonymity sets; see Section 6.2 for more + information about these privacy considerations. + +3.5. Issuance Protocol + + The Privacy Pass issuance protocols, such as those described in + [ISSUANCE], are two-message protocols that take as input a + TokenChallenge from the redemption protocol ([AUTHSCHEME], + Section 2.1) and produce a token ([AUTHSCHEME], Section 2.2), as + shown in Figure 1. + + The structure and semantics of the TokenRequest and TokenResponse + messages depend on the issuance protocol and token type being used; + see [ISSUANCE] for more information. + + Clients interact with the Attester and Issuer to produce a token for + a challenge. The context in which an Attester vouches for a Client + during issuance is referred to as the attestation context. This + context includes all information associated with the issuance event, + such as the timestamp of the event and Client-visible information, + including the IP address or other information specific to the type of + attestation done. + + Each issuance protocol may be different, e.g., in the number and + types of participants, underlying cryptographic constructions used + when issuing tokens, and even privacy properties. + + Clients initiate the issuance protocol using the token challenge, a + randomly generated nonce, and a public key for the Issuer, all of + which are the Client's private input to the protocol and ultimately + bound to an output token; see Section 2.2 of [AUTHSCHEME] for + details. Future specifications may change or extend the Client's + input to the issuance protocol to produce tokens with a different + structure. + + Token properties vary based on the issuance protocol. Important + properties supported in this architecture are described below. + + 1. Public verifiability. This means that the token can be verified + using the Issuer Public Key. A token that does not have public + verifiability can only be verified using the Issuer secret key. + + 2. Public metadata. This means that the token can be + cryptographically bound to arbitrary public information. See + Section 6.1 for privacy considerations regarding public metadata. + + 3. Private metadata. This means that the token can be + cryptographically bound to arbitrary private information, i.e., + information that the Client does not observe during token + issuance or redemption. See Section 6.1 for privacy + considerations regarding private metadata. + + The issuance protocol itself can be any interactive protocol between + the Client, Issuer, or other parties that produces a valid token + bound to the Client's private input, subject to the following + security requirements. + + 1. Unconditional input secrecy. The issuance protocol MUST NOT + reveal anything about the Client's private input, including the + challenge and nonce, to the Attester or Issuer, regardless of the + hardness assumptions of the underlying cryptographic protocol(s). + This property is sometimes also referred to as blindness. + + 2. One-more forgery security. The issuance protocol MUST NOT allow + malicious Clients or Attesters (acting as Clients) to forge + tokens offline or otherwise without interacting with the Issuer + directly. + + 3. Concurrent security. The issuance protocol MUST be safe to run + concurrently with arbitrarily many Clients, Attesters, and + Issuers. + + See Section 3.5.4 for requirements on new issuance protocol variants + and related extensions. + + In the sections below, we describe the Attester and Issuer roles in + more detail. + +3.5.1. Attester Role + + In Privacy Pass, attestation is the process by which an Attester + bears witness to, confirms, or authenticates a Client so as to verify + properties about the Client that are required for issuance. Issuers + trust Attesters to perform attestation correctly, i.e., to implement + attestation procedures in such a way that those procedures are not + subverted or bypassed by malicious Clients. + + [RFC9334] describes an architecture for attestation procedures. + Using that architecture as a conceptual basis, Clients are RATS + Attesters that produce attestation evidence, and Attesters are RATS + Verifiers that appraise the validity of attestation evidence. + + The type of attestation procedure is a deployment-specific option and + outside the scope of the issuance protocol. Example attestation + procedures are below. + + * Solving a CAPTCHA. Clients that solve CAPTCHA challenges can be + attested to have this capability for the purpose of being ruled + out as a bot or otherwise automated Client. + + * Presenting evidence of Client device validity. Some Clients run + on trusted hardware that is capable of producing device-level + attestation evidence. + + * Proving properties about Client state. Clients can be associated + with state, and the Attester can verify this state. Examples of + state include the Client's geographic region and whether the + Client has a valid application-layer account. + + Attesters may support different types of attestation procedures. + + Each attestation procedure has different security properties. For + example, attesting to having a valid account is different from + attesting to running on trusted hardware. Supporting multiple + attestation procedures is an important step towards ensuring + equitable access for Clients; see Section 5.1. + + The role of the Attester in the issuance protocol and its impact on + privacy depend on the type of attestation procedure, issuance + protocol, and deployment model. For instance, increasing the number + of required attestation procedures could decrease the overall + anonymity set size. As an example, the number of Clients that have + solved a CAPTCHA in the past day, that have a valid account, and that + are running on a trusted device is less than the number of Clients + that have solved a CAPTCHA in the past day. See Section 6.2 for more + discussion of how the variety of attestation procedures can + negatively impact Client privacy. + + Depending on the issuance protocol, the Issuer might learn + information about the Origin. To ensure Issuer-Client unlinkability, + the Issuer should be unable to link that information to a specific + Client. For such issuance protocols where the Attester has access to + Client-specific information, such as is the case for attestation + procedures that involve Client-specific information (such as + application-layer account information) or for deployment models where + the Attester learns Client-specific information (such as Client IP + addresses), Clients trust the Attester to not share any Client- + specific information with the Issuer. In deployments where the + Attester does not learn Client-specific information or where the + Attester and Issuer are operated by the same entity (such as in the + Joint Attester and Issuer model described in Section 4.2), the Client + does not need to explicitly trust the Attester in this regard. + + Issuers trust Attesters to correctly and reliably perform + attestation. However, certain types of attestation procedures can + vary in value over time, e.g., if the attestation procedure is + compromised. Broken attestation procedures are considered + exceptional events and require configuration changes to address the + underlying cause. For example, if an attestation procedure is + compromised or subverted because of a zero-day exploit on devices + that implement the attestation procedure, then the corresponding + attestation procedure should be untrusted until the exploit is + patched. Addressing changes in attestation quality is therefore a + deployment-specific task. In Split Origin, Attester, and Issuer + deployments (see Section 4.4), Issuers can choose to remove + compromised Attesters from their trusted set until the compromise is + patched. + + From the perspective of an Origin, tokens produced by an Issuer with + at least one compromised Attester cannot be trusted, assuming that + the Origin does not know which attestation procedure was used for + issuance. This is because the Origin cannot distinguish between + tokens that were issued via compromised Attesters and tokens that + were issued via uncompromised Attesters, absent some distinguishing + information in the tokens themselves or from the Issuer. As a + result, until the attestation procedure is fixed, the Issuer cannot + be trusted by Origins. Moreover, as a consequence, any tokens issued + by an Issuer with a compromised Attester may no longer be trusted by + Origins, even if those tokens were issued to Clients interacting with + an uncompromised Attester. + +3.5.2. Issuer Role + + In Privacy Pass, the Issuer is responsible for completing the + issuance protocol for Clients that complete attestation through a + trusted Attester. As described in Section 3.5.1, Issuers explicitly + trust Attesters to correctly and reliably perform attestation. + Origins explicitly trust Issuers to only issue tokens from trusted + Attesters. Clients do not explicitly trust Issuers. + + Depending on the deployment model case, issuance may require some + form of Client anonymization service, similar to an IP-hiding proxy, + so that Issuers cannot learn information about Clients. This can be + provided by an explicit participant in the issuance protocol, or it + can be provided via external means, such as through the use of an IP- + hiding proxy service like Tor [DMS2004]. In general, Clients SHOULD + minimize or remove identifying information where possible when + invoking the issuance protocol. + + Issuers are uniquely identifiable by all Clients with a consistent + identifier. In a web context, this identifier might be the Issuer + hostname. Issuers maintain one or more configurations, including + issuance key pairs, for use in the issuance protocol. Each + configuration is assumed to have a unique and canonical identifier, + sometimes referred to as a key identifier or key ID. Issuers can + rotate these configurations as needed to mitigate the risk of + compromise; see Section 6.2 for more considerations around + configuration rotation. The Issuer Public Key for each active + configuration is made available to Origins and Clients for use in the + issuance and redemption protocols. + +3.5.3. Issuance Metadata + + Certain instantiations of the issuance protocol may permit public or + private metadata to be cryptographically bound to a token. As an + example, one trivial way to include public metadata is to assign a + unique Issuer Public Key for each value of metadata, such that N keys + yield log_2(N) bits of metadata. Metadata may be public or private. + + Public metadata is metadata that Clients can observe as part of the + token issuance flow. Public metadata can be either transparent or + opaque. For example, transparent public metadata is a value that + either the Client generates itself or the Issuer provides during the + issuance flow and that the Client can check for correctness. Opaque + public metadata is metadata the Client can see but cannot check for + correctness. As an example, the opaque public metadata might be a + "fraud detection signal", computed on behalf of the Issuer, during + token issuance. Generally speaking, Clients cannot determine if this + value is generated in a way that permits tracking. + + Private metadata is metadata that Clients cannot observe as part of + the token issuance flow. Such instantiations can be built on the + private metadata bit construction from Kreuter et al. [KLOR20] or the + attribute-based Verifiable Oblivious Pseudorandom Function (VOPRF) + from Huang et al. [HIJK21]. + + Metadata can be arbitrarily long or bounded in length. The amount of + permitted metadata may be determined by an application or by the + underlying cryptographic protocol. The total amount of metadata bits + included in a token is the sum of public and private metadata bits. + Every bit of metadata can be used to partition the Client issuance or + redemption anonymity sets; see Section 6.1 for more information. + +3.5.4. Future Issuance Protocol Requirements + + The Privacy Pass architecture and ecosystem are both intended to be + receptive to extensions that expand the current set of + functionalities through new issuance protocols. Each new issuance + protocol and extension MUST adhere to the following requirements: + + 1. Include a detailed analysis of the privacy impacts of the + extension, why these impacts are justified, and guidelines on how + to use the protocol to mitigate or minimize negative deployment + or privacy consequences discussed in Sections 5 and 6, + respectively. + + 2. Adhere to the guidelines specified in Section 3.5.2 for managing + Issuer Public Key data. + + 3. Clearly specify how to interpret and validate TokenChallenge and + token messages that are exchanged during the redemption protocol. + +3.6. Information Flow + + The end-to-end process of redemption and issuance protocols involves + information flowing between the Issuer, Origin, Client, and Attester. + That information can have implications on the privacy goals that + Privacy Pass aims to provide as outlined in Section 3.3. In this + section, we describe the flow of information between each party. How + this information affects the privacy goals in particular deployment + models is further discussed in Section 4. + +3.6.1. Token Challenge Flow + + To use Privacy Pass, Origins choose an Issuer from which they are + willing to accept tokens. Origins then construct a token challenge + using this specified Issuer and information from the redemption + context it shares with the Client. This token challenge is then + delivered to a Client. The token challenge conveys information about + the Issuer and the redemption context, such as whether the Origin + desires a per-Origin or cross-Origin token. Any entity that sees the + token challenge might learn things about the Client as known to the + Origin. This is why input secrecy is a requirement for issuance + protocols, as it ensures that the challenge is not directly available + to the Issuer. + +3.6.2. Attestation Flow + + Clients interact with the Attester to prove that they meet some + required set of properties. In doing so, Clients contribute + information to the attestation context, which might include sensitive + information such as application-layer identities, IP addresses, and + so on. Clients can choose whether or not to contribute this + information based on local policy or preference. + +3.6.3. Issuance Flow + + Clients use the issuance protocol to produce a token bound to a token + challenge. In doing so, there are several ways in which the issuance + protocol contributes information to the attestation or issuance + contexts. For example, a token request may contribute information to + the attestation or issuance contexts as described below. + + * Issuance protocol. The type of issuance protocol can contribute + information about the Issuer's capabilities to the attestation or + issuance contexts, as well as the capabilities of a given Client. + For example, if a Client is presented with multiple issuance + protocol options, then the choice of which issuance protocol to + use can contribute information about the Client's capabilities. + + * Issuer configuration. Information about the Issuer configuration, + such as its identity or the public key used to validate tokens it + creates, can be revealed during issuance and contribute to the + attestation or issuance contexts. + + * Attestation information. The issuance protocol can contribute + information to the attestation or issuance contexts based on what + attestation procedure the Issuer uses to trust a token request. + In particular, a token request that is validated by a given + Attester means that the Client that generated the token request + must be capable of completing the designated attestation + procedure. + + * Origin information. The issuance protocol can contribute + information about the Origin that challenged the Client; see + Section 3.6.1. In particular, a token request designated for a + specific Issuer might imply that the resulting token is for an + Origin that trusts the specified Issuer. However, this is not + always true, as some token requests can correspond to cross-Origin + tokens, i.e., they are tokens that would be accepted at any Origin + that accepts the cross-Origin token. + + Moreover, a token may contribute information to the issuance + attestation or contexts as described below. + + * Origin information. The issuance protocol can contribute + information about the Origin in how it responds to a token + request. For example, if an Issuer learns the Origin during + issuance and is also configured to respond in some way on the + basis of that information, and the Client interacts with the + Issuer transitively through the Attester, that response can reveal + information to the Attester. + + * Token. The token produced by the issuance protocol can contain + information from the issuance context. In particular, depending + on the issuance protocol, tokens can contain public or private + metadata, and Issuers can choose that metadata on the basis of + information in the issuance context. + + Exceptional cases in the issuance protocol, such as when either the + Attester or Issuer aborts the protocol, can contribute information to + the attestation or issuance contexts. The extent to which + information in this context harms the Issuer-Client or Attester- + Origin unlinkability goals as discussed in Section 3.3 depends on the + deployment model; see Section 4. Clients can choose whether or not + to contribute information to these contexts based on local policy or + preference. + +3.6.4. Token Redemption Flow + + Clients send tokens to Origins during the redemption protocol. Any + information that is added to the token during issuance can therefore + be sent to the Origin. Information can be either (1) explicitly + passed in a token or (2) implicit in the way the Client responds to a + token challenge. For example, if a Client fails to complete issuance + and consequently fails to redeem a token for a token challenge, this + can reveal information to the Origin that it might not otherwise have + access to. However, an Origin cannot necessarily distinguish between + a Client that fails to complete issuance and one that ignores the + token challenge altogether. + +4. Deployment Models + + The Origin, Attester, and Issuer portrayed in Figure 1 can be + instantiated and deployed in a number of ways. The deployment model + directly influences the manner in which attestation, issuance, and + redemption contexts are separated to achieve Origin-Client, Issuer- + Client, and Attester-Origin unlinkability. + + This section covers some expected deployment models and their + corresponding security and privacy considerations. Each deployment + model is described in terms of the trust relationships and + communication patterns between the Client, Attester, Issuer, and + Origin. Entities drawn within the same bounding box are assumed to + be operated by the same party and are therefore able to collude. + Collusion can enable linking of attestation, issuance, and redemption + contexts. Entities not drawn within the same bounding box (i.e., + operated by separate parties) are assumed to not collude. Mechanisms + for enforcing non-collusion are out of scope for this architecture. + +4.1. Shared Origin, Attester, Issuer + + In this model, the Origin, Attester, and Issuer are all operated by + the same entity, as shown in Figure 3. + + +---------------------------------------------. + +--------+ | +----------+ +--------+ +--------+ | + | Client | | | Attester | | Issuer | | Origin | | + +---+----+ | +-----+----+ +----+---+ +---+----+ | + | `-------|---------------|-------------|------' + |<-------------------------------- TokenChallenge --+ + | | | | + |<=== Attestation ===>| | | + | | | | + +----------- TokenRequest ----------->| | + |<---------- TokenResponse -----------+ | + | | + +--------------------- Token -----------------------> + | | + + Figure 3: Shared Deployment Model + + This model represents the initial deployment of Privacy Pass, as + described in [PrivacyPassCloudflare]. In this model, the Attester, + Issuer, and Origin share the attestation, issuance, and redemption + contexts. As a result, attestation mechanisms that can uniquely + identify a Client, e.g., requiring that Clients authenticate with + some type of application-layer account, are not appropriate, as they + could lead to unlinkability violations. + + Origin-Client, Issuer-Client, and Attester-Origin unlinkability + requires that issuance and redemption events be separated over time, + such as through the use of tokens that correspond to token challenges + with an empty redemption context (see Section 3.4), or that they be + separated over space, such as through the use of an anonymizing + service when connecting to the Origin. + +4.2. Joint Attester and Issuer + + In this model, the Attester and Issuer are operated by the same + entity, separate from the Origin. The Origin trusts the joint + Attester and Issuer to perform attestation and issue tokens. Clients + interact with the joint Attester and Issuer for attestation and + issuance. This arrangement is shown in Figure 4. + + +------------------------------. + +--------+ | +----------+ +--------+ | +--------+ + | Client | | | Attester | | Issuer | | | Origin | + +---+----+ | +-----+----+ +----+---+ | +---+----+ + | `-------|---------------|-----' | + |<---------------------------------- TokenChallenge --+ + | | | | + |<==== Attestation ====>| | | + | | | | + +------------- TokenRequest ----------->| | + |<----------- TokenResponse ------------+ | + | | + +----------------------- Token -----------------------> + | | + + Figure 4: Joint Attester and Issuer Deployment Model + + This model is useful if an Origin wants to offload attestation and + issuance to a trusted entity. In this model, the Attester and Issuer + share an attestation and issuance context for the Client, separate + from the Origin's redemption context. + + Similar to the shared Origin, Attester, Issuer model, Issuer-Client + and Origin-Client unlinkability in this model requires that issuance + and redemption events, respectively, be separated over time or space. + Attester-Origin unlinkability requires that the Attester and Issuer + do not learn the Origin for a particular token request. For this + reason, issuance protocols that require the Issuer to learn + information about the Origin, such as the issuance protocol described + in [RATE-LIMITED], are not appropriate, since they could lead to + Attester-Origin unlinkability violations through the Origin name. + +4.3. Joint Origin and Issuer + + In this model, the Origin and Issuer are operated by the same entity, + separate from the Attester, as shown in Figure 5. The Issuer accepts + token requests that come from trusted Attesters. Since the Attester + and Issuer are separate entities, this model requires some mechanism + by which Issuers establish trust in the Attester (as described in + Section 3.3). For example, in settings where the Attester is a + Client-trusted service that directly communicates with the Issuer, + one way to establish this trust is via mutually authenticated TLS. + However, alternative authentication mechanisms are possible. In this + model, the Origin and Issuer are operated by the same entity, + separate from the Attester, as shown in the figure below. + + +----------------------------. + +--------+ +----------+ | +--------+ +--------+ | + | Client | | Attester | | | Issuer | | Origin | | + +---+----+ +-----+----+ | +----+---+ +---+----+ | + | | `------|-------------|------' + |<-------------------------------- TokenChallenge --+ + | | | | + |<=== Attestation ===>| | | + | | | | + +------------ TokenRequest ---------->| | + |<---------- TokenResponse -----------+ | + | | + +--------------------- Token -----------------------> + | | + + Figure 5: Joint Origin and Issuer Deployment Model + + This model is useful for Origins that require Client-identifying + attestation, e.g., through the use of application-layer account + information, but do not otherwise want to learn information about + individual Clients beyond what is observed during the token + redemption, such as Client IP addresses. + + In this model, attestation contexts are separate from Issuer and + redemption contexts. As a result, any type of attestation is + suitable in this model. + + Moreover, assuming that there is more than one Origin involved, any + type of token challenge is suitable, since no single party will have + access to the identifying Client information and unique Origin + information. Issuers that produce tokens for a single Origin are not + suitable in this model, since an Attester can infer the Origin from a + token request, as described in Section 3.6.3. However, since the + issuance protocol provides input secrecy, the Attester does not learn + details about the corresponding token challenge, such as whether the + token challenge is per Origin or across Origins. + +4.4. Split Origin, Attester, Issuer + + In this model, the Origin, Attester, and Issuer are all operated by + different entities. As with the Joint Origin and Issuer model + (Section 4.3), the Issuer accepts token requests that come from + trusted Attesters, and the details of that trust establishment depend + on the issuance protocol and relationship between the Attester and + Issuer; see Section 3.3. This arrangement is shown in Figure 1. + + This is the most general deployment model and is necessary for some + types of issuance protocols where the Attester plays a role in token + issuance; see [RATE-LIMITED] for one such type of issuance protocol. + + In this model, the Attester, Issuer, and Origin have a separate view + of the Client: the Attester sees potentially sensitive Client- + identifying information, such as account identifiers or IP addresses; + the Issuer sees only the information necessary for issuance; and the + Origin sees token challenges, corresponding tokens, and Client source + information, such as their IP address. As a result, attestation, + issuance, and redemption contexts are separate, and therefore any + type of token challenge is suitable in this model as long as there is + more than a single Origin. + + As with the Joint Origin and Issuer model (Section 4.3), and as + described in Section 3.6.3, if the Issuer produces tokens for a + single Origin, then per-Origin tokens are not appropriate, since the + Attester can infer the Origin from a token request. + +5. Deployment Considerations + + Section 4 discusses deployment models that are possible in practice. + Beyond possible implications on security and privacy properties of + the resulting system, Privacy Pass deployments can impact the overall + ecosystem in two important ways: (1) discriminatory treatment of + Clients and the gated access to otherwise open services and + (2) centralization. This section describes considerations relevant + to these topics. + +5.1. Discriminatory Treatment + + Origins can use tokens as a signal for distinguishing between + (1) Clients that are capable of completing attestation with one + Attester trusted by the Origin's chosen Issuer and (2) Clients that + are not capable of doing the same. A consequence of this is that + Privacy Pass could enable discriminatory treatment of Clients based + on attestation support. For example, an Origin could only authorize + Clients that successfully authenticate with a token, prohibiting + access to all other Clients. + + The types of attestation procedures supported for a particular + deployment depend greatly on the use case. For example, consider a + proprietary deployment of Privacy Pass that authorizes Clients to + access a resource such as an anonymization service. In this context, + it is reasonable to support specific types of attestation procedures + that demonstrate that Clients can access the resource, such as with + an account or specific type of device. However, in open deployments + of Privacy Pass that are used to safeguard access to otherwise open + or publicly accessible resources, diversity in attestation procedures + is critically important so as to not discriminate against Clients + that choose certain software, hardware, or identity providers. + + In principle, Issuers should strive to mitigate discriminatory + behavior by providing equitable access to all Clients. This can be + done by working with a set of Attesters that are suitable for all + Clients. In practice, this may require trade-offs in what type of + attestation Issuers are willing to trust so as to enable more + widespread support. In other words, trusting a variety of Attesters + with a diverse set of attestation procedures would presumably + increase support among Clients, though most likely at the expense of + decreasing the overall value of tokens issued by the Issuer. + + For example, to disallow discriminatory behavior between Clients with + and without device attestation support, an Issuer may wish to support + Attesters that support CAPTCHA-based attestation. This means that + the overall attestation value of a Privacy Pass token is bound by the + difficulty in spoofing or bypassing either one of these attestation + procedures. + +5.2. Centralization + + A consequence of limiting the number of participants (Attesters or + Issuers) in Privacy Pass deployments for meaningful privacy is that + it forces concentrated centralization among those participants. + [CENTRALIZATION] discusses several ways in which this might be + mitigated. For example, a multi-stakeholder governance model could + be established to determine what candidate participants are fit to + operate as participants in a Privacy Pass deployment. This is + precisely the system used to control the Web's trust model. + + Alternatively, Privacy Pass deployments might mitigate this problem + through implementation. For example, rather than centralize the role + of attestation in one or a few entities, attestation could be a + distributed function performed by a quorum of many parties, provided + that neither Issuers nor Origins learn which Attester implementations + were chosen. As a result, Clients could have more opportunities to + switch between attestation participants. + +6. Privacy Considerations + + The previous section discusses the impact of deployment details on + Origin-Client, Issuer-Client, and Attester-Origin unlinkability. The + value these properties afford to end users depends on the size of + anonymity sets in which Clients or Origins are unlinkable. For + example, consider two different deployments, one wherein there exists + a redemption anonymity set of size two and another wherein there + exists a redemption anonymity set of size 2^32. Although Origin- + Client unlinkability guarantees that the Origin cannot link any two + requests to the same Client based on these contexts, respectively, + the smaller these sets become, the higher the probability of + determining the "true" Client. + + In practice, there are a number of ways in which the size of + anonymity sets may be reduced or partitioned, though they all center + around the concept of consistency. In particular, by definition, all + Clients in an anonymity set share a consistent view of information + needed to run the issuance and redemption protocols. The Issuer + Public Key is an example of the type of information needed to run + these protocols. When two Clients have inconsistent information, + these Clients effectively have different redemption contexts and + therefore belong in different anonymity sets. + + The following subsections discuss issues that can influence anonymity + set size. For each issue, we discuss mitigations or safeguards to + protect against the underlying problem. + +6.1. Partitioning by Issuance Metadata + + Any public or private metadata bits of information can be used to + further segment the size of the Client anonymity set. Any Issuer + that wanted to track a single Client could add a single metadata bit + to Client tokens. For the tracked Client, it would set the bit to 1, + and 0 otherwise. Adding additional bits provides an exponential + increase in tracking granularity in a manner similar to introducing + more Issuers (though with more potential targeting). + + For this reason, deployments should take the amount of metadata used + by an Issuer in creating tokens, together with the bits of + information that Issuers may learn about Clients through other means, + into account. Since this metadata may be useful for practical + deployments of Privacy Pass, Issuers must balance this against the + reduction in Client privacy. + + The number of permitted metadata values often depends on deployment- + specific details. In general, limiting the amount of metadata + permitted helps limit the extent to which metadata can uniquely + identify individual Clients. Failure to bound the number of possible + metadata values can therefore lead to a reduction in Client privacy. + Most token types do not admit any metadata, so this bound is + implicitly enforced. + +6.2. Partitioning by Issuance Consistency + + Anonymity sets can be partitioned by information used for the + issuance protocol, including metadata, Issuer configuration (keys), + and Issuer selection. + + Any issuance metadata bits of information can be used to partition + the Client anonymity set. For example, any Issuer that wanted to + track a single Client could add a single metadata bit to Client + tokens. For the tracked Client, it would set the bit to 1, and 0 + otherwise. Adding additional bits provides an exponential increase + in tracking granularity in a manner similar to introducing more + Issuers (though with more potential targeting). + + The number of active Issuer configurations also contributes to + anonymity set partitioning. In particular, when an Issuer updates + their configuration and the corresponding key pair, any Client that + invokes the issuance protocol with this configuration becomes part of + a set of Clients that also ran the issuance protocol using the same + configuration. Issuer configuration updates, e.g., due to key + rotation, are an important part of hedging against long-term private + key compromise. In general, key rotations represent a trade-off + between Client privacy and Issuer security. Therefore, it is + important that key rotations occur on a regular cycle to reduce the + harm of an Issuer key compromise. + + Lastly, if Clients are willing to issue and redeem tokens from a + large number of Issuers for a specific Origin and that Origin accepts + tokens from all Issuers, partitioning can occur. As an example, if a + Client obtains tokens from many Issuers and an Origin later + challenges that Client for a token from each Issuer, the Origin can + learn information about the Client. This arrangement might happen if + Clients request tokens from different Issuers, each of which has + different Attester preferences. Each per-Issuer token that a Client + holds essentially corresponds to a bit of information about the + Client that the Origin learns. Therefore, there is an exponential + loss in privacy relative to the number of Issuers. + + The fundamental problem here is that the number of possible issuance + configurations, including the keys in use and the Issuer identities + themselves, can partition the Client anonymity set. To mitigate this + problem, Clients SHOULD bound the number of active issuance + configurations per Origin as well as across Origins. Moreover, + Clients SHOULD employ some form of consistency mechanism to ensure + that they receive the same configuration information and are not + being actively partitioned into smaller anonymity sets. See + [CONSISTENCY] for possible consistency mechanisms. Depending on the + deployment, the Attester might assist the Client in applying these + consistency checks across Clients. Failure to apply a consistency + check can allow Client-specific keys to violate Origin-Client + unlinkability. + +6.3. Partitioning by Side Channels + + Side-channel attacks, such as those based on timing correlation, + could be used to reduce anonymity set size. In particular, for + interactive tokens that are bound to a Client-specific redemption + context, the anonymity set of Clients during the issuance protocol + consists of those Clients that started issuance between the time of + the Origin's challenge and the corresponding token redemption. + Depending on the number of Clients using a particular Issuer during + that time window, the set can be small. Applications should take + such side channels into consideration before choosing a particular + deployment model and type of token challenge and redemption context. + +7. Security Considerations + + This document describes security and privacy requirements for the + Privacy Pass redemption and issuance protocols. It also describes + deployment models built around non-collusion assumptions and privacy + considerations for using Privacy Pass within those models. Ensuring + Client privacy -- separation of attestation and redemption contexts + -- requires active work on behalf of the Client, especially in the + presence of malicious Issuers and Origins. Implementing the + mitigations discussed in Sections 4 and 6 is therefore necessary to + ensure that Privacy Pass offers meaningful privacy improvements to + end users. + +7.1. Token Caching + + Depending on the Origin's token challenge, Clients can request and + cache more than one token using an issuance protocol. Cached tokens + help improve privacy by separating the time of token issuance from + the time of token redemption; they also allow Clients to reduce the + overhead of receiving new tokens via the issuance protocol. + + As a consequence, Origins that send token challenges that are + compatible with cached tokens need to take precautions to ensure that + tokens are not replayed. This is typically done via keeping track of + tokens that are redeemed for the period of time in which cached + tokens would be accepted for particular challenges. + + Moreover, since tokens are not intrinsically bound to Clients, it is + possible for malicious Clients to collude and share tokens in a so- + called "hoarding attack". As an example of this attack, many + distributed Clients could obtain cacheable tokens and then share them + with a single Client to redeem the tokens in a way that would violate + an Origin's attempt to limit tokens to any one particular Client. In + general, mechanisms for mitigating hoarding attacks depend on the + deployment model and use case. For example, in the Joint Origin and + Issuer model, comparing the issuance and redemption contexts can help + detect hoarding attacks, i.e., if the distribution of redemption + contexts is noticeably different from the distribution of issuance + contexts. Rate-limiting issuance, at either the Client, Attester, or + Issuer, can also help mitigate these attacks. + +8. IANA Considerations + + This document has no IANA actions. + +9. References + +9.1. Normative References + + [AUTHSCHEME] + Pauly, T., Valdez, S., and C. A. Wood, "The Privacy Pass + HTTP Authentication Scheme", RFC 9577, + DOI 10.17487/RFC9577, June 2024, + <https://www.rfc-editor.org/info/rfc9577>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + +9.2. Informative References + + [CENTRALIZATION] + Nottingham, M., "Centralization, Decentralization, and + Internet Standards", RFC 9518, DOI 10.17487/RFC9518, + December 2023, <https://www.rfc-editor.org/info/rfc9518>. + + [CONSISTENCY] + Davidson, A., Finkel, M., Thomson, M., and C. A. Wood, + "Key Consistency and Discovery", Work in Progress, + Internet-Draft, draft-ietf-privacypass-key-consistency-01, + 10 July 2023, <https://datatracker.ietf.org/doc/html/ + draft-ietf-privacypass-key-consistency-01>. + + [DMS2004] Dingledine, R., Mathewson, N., and P. Syverson, "Tor: The + Second-Generation Onion Router", May 2004, + <https://svn.torproject.org/svn/projects/design-paper/tor- + design.html>. + + [HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee, + C-K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S., + Sung, Y-C., and A. Zhang, "DIT: De-Identified + Authenticated Telemetry at Scale", January 2021, + <https://research.fb.com/privatestats>. + + [ISSUANCE] Celi, S., Davidson, A., Valdez, S., and C. A. Wood, + "Privacy Pass Issuance Protocols", RFC 9578, + DOI 10.17487/RFC9578, June 2024, + <https://www.rfc-editor.org/info/rfc9578>. + + [KLOR20] Kreuter, B., Lepoint, T., Orrù, M., Raykova, M., and + Springer International Publishing, "Anonymous Tokens with + Private Metadata Bit", Advances in Cryptology - CRYPTO + 2020, pp. 308-336, DOI 10.1007/978-3-030-56784-2_11, 2020, + <https://doi.org/10.1007/978-3-030-56784-2_11>. + + [OHTTP] Thomson, M. and C. A. Wood, "Oblivious HTTP", RFC 9458, + DOI 10.17487/RFC9458, January 2024, + <https://www.rfc-editor.org/info/rfc9458>. + + [PrivacyPassCloudflare] + Sullivan, N., "Cloudflare supports Privacy Pass", November + 2017, <https://blog.cloudflare.com/cloudflare-supports- + privacy-pass/>. + + [RATE-LIMITED] + Hendrickson, S., Iyengar, J., Pauly, T., Valdez, S., and + C. A. Wood, "Rate-Limited Token Issuance Protocol", Work + in Progress, Internet-Draft, draft-ietf-privacypass-rate- + limit-tokens-06, 1 April 2024, + <https://datatracker.ietf.org/doc/html/draft-ietf- + privacypass-rate-limit-tokens-06>. + + [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and + W. Pan, "Remote ATtestation procedureS (RATS) + Architecture", RFC 9334, DOI 10.17487/RFC9334, January + 2023, <https://www.rfc-editor.org/info/rfc9334>. + +Acknowledgements + + The authors would like to thank Eric Kinnear, Scott Hendrickson, + Tommy Pauly, Christopher Patton, Benjamin Schwartz, Martin Thomson, + Steven Valdez, and other contributors of the Privacy Pass Working + Group for many helpful contributions to this document. + +Authors' Addresses + + Alex Davidson + NOVA LINCS, Universidade NOVA de Lisboa + Largo da Torre + Caparica + Portugal + Email: alex.davidson92@gmail.com + + + Jana Iyengar + Fastly + Email: jri@fastly.com + + + Christopher A. Wood + Cloudflare + 101 Townsend St + San Francisco, CA 94107 + United States of America + Email: caw@heapingbits.net |