| RFC 9576 | Privacy Pass Architecture | June 2024 |
| Davidson, et al. | Informational | [Page] |
This document specifies the Privacy Pass architecture and requirements forits constituent protocols used for authorization based on privacy-preservingauthentication mechanisms. It describes the conceptual model of Privacy Passand its protocols, its security and privacy goals, practical deployment models,and recommendations for each deployment model, to help ensure that the desiredsecurity and privacy goals are fulfilled.¶
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 athttps://www.rfc-editor.org/info/rfc9576.¶
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.¶
Privacy Pass is an architecture for authorization based on privacy-preservingauthentication mechanisms. In other words, relying parties authenticate Clientsin a privacy-preserving way, i.e., without learning any unique, per-Clientinformation through the authentication protocol, and then make authorizationdecisions on the basis of that authentication succeeding or failing. Possibleauthorization decisions might be to provide Clients with read access to aparticular resource or write access to a particular resource.¶
Typical approaches for authorizing Clients, such as through the use of long-termstate (cookies), are not privacy friendly, since they allow servers to trackClients across sessions and interactions. Privacy Pass takes a differentapproach: instead of presenting linkable state-carrying information to servers,e.g., a cookie indicating whether or not the Client is an authorized user orhas completed some prior challenge, Clients present unlinkable proofs thatattest to this information. These proofs, or tokens, are private in the sensethat a given token cannot be linked to the protocol interaction where thattoken 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 andOrigins (servers). It allows Origins to challenge Clients to present tokensfor consumption. Origins verify the token to authenticate the Client -- withoutlearning any specific information about the Client -- and then make an authorizationdecision on the basis of the token verifying successfully or not. Dependingon the type of token, e.g., whether or not it can be cached, the Clienteither presents a previously obtained token or invokes an issuance protocol,e.g., the protocols described in[ISSUANCE], to acquire a token topresent as authorization.¶
This document describes requirements for both redemption and issuanceprotocols and how they interact. It also provides recommendations on howthe architecture should be deployed to ensure the privacy of Clients andthe security of all participating entities.¶
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:¶
An entity that seeks authorization to an Origin. Using terminology from[RFC9334],Clients implement the Remote ATtestation procedureS (RATS) Attester role.¶
A cryptographic authentication message used for authorization decisions,produced as output from an issuance mechanism or protocol.¶
An entity that consumes tokens presented by Clients and uses them to make authorization decisions.¶
The mechanism by which Origins request tokens from Clients, often denoted TokenChallenge.¶
A message used by Clients to request a token from an Issuer, often denoted TokenRequest.¶
A message used by Issuers to send tokens to a Client, often denoted TokenResponse.¶
The mechanism by which Clients present tokens to Origins for thepurposes of authorization.¶
An entity that issues tokens to Clients for propertiesattested to by the Attester.¶
The mechanism by which an Issuer produces tokens for Clients.¶
An entity that attests to properties of Clients for thepurposes of token issuance. Using terminology from[RFC9334], Attesters implement the RATS Verifier role.¶
The procedure by which an Attester determines whether or not a Clienthas the specific set of properties that are necessary for token issuance.¶
The trust relationships between each of the entities in this list are furtherelaborated upon inSection 3.3.¶
The Privacy Pass architecture consists of four logical entities --Client, Origin, Issuer, and Attester -- that work in concertfor token redemption and issuance. This section presents an overviewof Privacy Pass, a high-level description of the threat model andprivacy goals of the architecture, and the goals and requirements ofthe redemption and issuance protocols. Deployment variations for theOrigin, Issuer, and Attester in this architecture, includingconsiderations for implementing these entities, are further discussedinSection 4.¶
This section describes the typical interaction flow for Privacy Pass, as shown inFigure 1.¶
If the Client has a token, it includes it in a subsequent request tothe Origin, as authorization. This token is sent only once in reaction to achallenge; Clients do not send tokens more than once, even if they receiveduplicate or redundant challenges. The Originvalidates that the token was generated by the expected Issuer and has notalready been redeemed for the corresponding token challenge. If the Clientdoes not have a token, perhaps because issuance failed, the Client does notreply to the Origin's challenge with a new request.¶
Use cases for Privacy Pass are broad and depend greatly on the deployment modelas discussed inSection 4. The initial motivating use case for Privacy Pass[PrivacyPassCloudflare] was to help rate-limit malicious or otherwise abusivetraffic from services such as Tor[DMS2004]. The generalized and evolvedarchitecture described in this document also works for this use case. However,for added clarity, some more possible use cases are described below.¶
The end-to-end flow for Privacy Pass described inSection 3.1 involves threedifferent types of contexts:¶
The interactions and set of information sharedbetween the Client and Origin, i.e., the information that is provided orotherwise available to the Origin during redemption that might be usedto identify a Client and construct a token challenge. This context includes allinformation associated with redemption, such as the timestamp of the event,Client-visible information (including the IP address), and the Origin name.¶
The interactions and set of information shared between the Client, Attester,and Issuer, i.e., the information that is provided or otherwise availableto the Attester and Issuer during issuance that might be used to identify a Client.This context includes all information associated with issuance, such as thetimestamp of the event, any Client-visible information (including the IPaddress), and the Origin name (if revealed during issuance). This does notinclude the token challenge in its entirety, as that is kept secret from theIssuer during the issuance protocol.¶
The interactions and set of information shared betweenthe Client and Attester only, for the purposes of attesting the validity ofthe Client, that is provided or otherwise available during attestation thatmight be used to identify the Client. This context includes all informationassociated with attestation, such as the timestamp of the event and anyClient-visible information, including information needed for the attestationprocedure to complete.¶
The privacy goals of Privacy Pass assume a threat model in which Origins trustspecific Issuers to produce tokens, and Issuers in turn trust one or moreAttesters to correctly run the attestation procedure with Clients. Thisarrangement ensures that tokens that validate for a given Issuer were onlyissued to a Client that successfully completed attestation with an Attesterthat the Issuer trusts. Moreover, this arrangement means that if an Originaccepts tokens issued by an Issuer that trusts multiple Attesters, then aClient can use any one of these Attesters to issue and redeem tokens for theOrigin. Whether or not these different entities in the architecture colludefor learning redemption, issuance, or attestation contexts, as well as thenecessary preconditions for context unlinkability, depends on the deploymentmodel; seeSection 4 for more details.¶
The mechanisms for establishing trust between each entity in this arrangementare deployment specific. For example, in settings where Clients interact withIssuers through an Attester, Attesters and Issuers might usemutually authenticated TLS to authenticate one another. In settings whereClients do not communicate with Issuers through an Attester, the Attestersmight convey this trust via a digital signature that Issuers can verify.¶
Clients explicitly trust Attesters to perform attestation correctly and in away that does not violate their privacy. In particular, this means that Attestersthat may be privy to private information about Clients are trusted to not disclosethis information to non-colluding parties. Colluding parties are assumed to haveaccess to the same information; seeSection 4 for more about differentdeployment models and non-collusion assumptions. However, Clients assume that Issuers andOrigins are malicious.¶
Given this threat model, the privacy goals of Privacy Pass are oriented aroundunlinkability based on redemption, issuance, and attestation contexts, asdescribed below.¶
These unlinkability properties ensure that only the Clients are able to correlateinformation that might be used to identify them with activity on the Origin.The Attester, Issuer, and Origin only receive the information necessary to performtheir respective functions.¶
The manner in which these unlinkability properties are achieved depends on thedeployment model, type of attestation, and issuance protocol details. For example,as discussed inSection 4, in some cases it is necessary to use an anonymizationservice that hides Client IP addresses, such as Tor[DMS2004]. In general,anonymization services ensure that all Clients that use the service are indistinguishablefrom one another, though in practice there may be small distinguishing features(TLS fingerprints, HTTP headers, etc.). Moreover, Clients generally trust these servicesto not disclose private Client information (such as IP addresses) to untrusted parties.Failure to use an anonymization service when interacting with Attesters, Issuers, orOrigins can allow the set of possible Clients to be partitioned by the Client's IP addressand can therefore lead to unlinkability violations. Similarly, malicious Originsmay attempt to link two redemption contexts together by using Client-specificIssuer Public Keys. See Sections 5 and6 for moreinformation.¶
Sections3.4 and3.5 describe the functional properties and securityrequirements of the redemption and issuance protocols in more detail.Section 3.6describes how information flows between the Issuer, Origin, Client, and Attesterthrough these protocols.¶
The Privacy Pass redemption protocol, described in[AUTHSCHEME], is an authorization protocolwherein Clients present tokens to Origins for authorization. Normally,redemption is preceded by a challenge, wherein the Origin challengesClients 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.¶
Alternatively, when configured to do so, Clients may opportunistically presenttoken values to Origins without a corresponding TokenChallenge.¶
The structure and semantics of the TokenChallenge and token messages dependon the issuance protocol and token type being used; see[AUTHSCHEME] formore information.¶
The challenge provides the Client with the information necessary to obtaintokens 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:¶
Origins that admit cross-Origin tokens bear some risk of allowing tokensissued for one Origin to be spent in an interaction with another Origin.In particular, cross-Origin tokens issued based on a challenge forone Origin can be redeemed at another Origin in the cross-Origin set,which can make it difficult to regulate token consumption. Depending on theuse case, Origins may need to maintain state to track redeemed tokens. Forexample, Origins that accept cross-Origin tokens across shared redemptioncontextsSHOULD track which tokens have already been redeemed in thoseredemption contexts, since these tokens can be issued and then spent multipletimes for any such challenge. Note that Clients that redeem thesame token to multiple Origins do risk those Origins being able to linkClient activity together, which can disincentivize this behavior. SeeSection 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 choiceof Issuer can reveal information about the Client used to partition anonymitysets; seeSection 6.2 for more information about these privacyconsiderations.¶
The Privacy Pass issuance protocols, such as those described in[ISSUANCE], are two-messageprotocols that take as input a TokenChallenge from the redemption protocol([AUTHSCHEME],Section 2.1) and produce a token([AUTHSCHEME],Section 2.2), as shown inFigure 1.¶
The structure and semantics of the TokenRequest and TokenResponse messagesdepend 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 fora challenge. The context in which an Attester vouches for a Client duringissuance is referred to as the attestation context. This context includes allinformation associated with the issuance event, such as the timestamp of theevent and Client-visible information, including the IP address or otherinformation specific to the type of attestation done.¶
Each issuance protocol may be different, e.g., in the number and types ofparticipants, underlying cryptographic constructions used when issuing tokens,and even privacy properties.¶
Clients initiate the issuance protocol using the token challenge, a randomlygenerated nonce, and a public key for the Issuer, all of which are the Client'sprivate input to the protocol and ultimately bound to an output token;seeSection 2.2 of [AUTHSCHEME] for details. Future specificationsmay change or extend the Client's input to the issuance protocol to producetokens with a different structure.¶
Token properties vary based on the issuance protocol. Important propertiessupported in this architecture are described below.¶
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'sprivate input, subject to the following security requirements.¶
SeeSection 3.5.4 for requirements on new issuance protocol variants andrelated extensions.¶
In the sections below, we describe the Attester and Issuer roles in moredetail.¶
In Privacy Pass, attestation is the process by which an Attester bearswitness to, confirms, or authenticates a Client so as to verify propertiesabout the Client that are required for issuance. Issuers trust Attestersto perform attestation correctly, i.e., to implement attestation proceduresin such a way that those procedures are not subverted or bypassed by malicious Clients.¶
[RFC9334] describes an architecture for attestation procedures. Usingthat architecture as a conceptual basis, Clients are RATS Attesters thatproduce attestation evidence, and Attesters are RATS Verifiers thatappraise the validity of attestation evidence.¶
The type of attestation procedure is a deployment-specific option and outsidethe scope of the issuance protocol. Example attestation procedures are below.¶
Attesters may support different types of attestation procedures.¶
Each attestation procedure has different security properties. Forexample, attesting to having a valid account is different from attesting torunning on trusted hardware. Supporting multiple attestation procedures isan important step towards ensuring equitable access for Clients; seeSection 5.1.¶
The role of the Attester in the issuance protocol and its impact on privacydepend on the type of attestation procedure, issuance protocol, and deploymentmodel. For instance, increasing the number of required attestation procedurescould decrease the overall anonymity set size. As an example, the number of Clientsthat have solved a CAPTCHA in the past day, that have a valid account, and thatare running on a trusted device is less than the number of Clients that havesolved a CAPTCHA in the past day. SeeSection 6.2 for more discussionof how the variety of attestation procedures can negatively impact Client privacy.¶
Depending on the issuance protocol, the Issuer might learninformation about the Origin. To ensure Issuer-Client unlinkability, the Issuershould be unable to link that information to a specific Client. For suchissuance protocols where the Attester has access to Client-specificinformation, such as is the case for attestation procedures that involveClient-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 anyClient-specific information with the Issuer. In deployments where the Attesterdoes not learn Client-specific information or where the Attester and Issuer areoperated by the same entity (such as in the Joint Attester and Issuer modeldescribed inSection 4.2), the Client does not need to explicitlytrust 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 theattestation procedure is compromised. Brokenattestation procedures are considered exceptional events and requireconfiguration changes to address the underlying cause. For example, ifan attestation procedure is compromised or subverted because of a zero-dayexploit on devices that implement the attestation procedure, then thecorresponding attestation procedure should be untrusted until the exploit ispatched. Addressing changes in attestation quality is therefore adeployment-specific task. In Split Origin, Attester, and Issuer deployments (seeSection 4.4), Issuers can choose to remove compromised Attesters fromtheir trusted set until the compromise is patched.¶
From the perspective of an Origin, tokens produced by an Issuer with at leastone compromised Attester cannot be trusted, assuming that the Origin does not knowwhich attestation procedure was used for issuance. This is because the Origincannot distinguish between tokens that were issued via compromised Attestersand tokens that were issued via uncompromised Attesters, absent somedistinguishing information in the tokens themselves or from the Issuer. As aresult, until the attestation procedure is fixed, the Issuer cannot be trustedby Origins. Moreover, as a consequence, any tokens issued by an Issuer with acompromised Attester may no longer be trusted by Origins, even if those tokenswere issued to Clients interacting with an uncompromised Attester.¶
In Privacy Pass, the Issuer is responsible for completing the issuance protocolfor Clients that complete attestation through a trusted Attester. As describedinSection 3.5.1, Issuers explicitly trust Attesters to correctly and reliablyperform attestation. Origins explicitly trust Issuers to only issue tokensfrom trusted Attesters. Clients do not explicitly trust Issuers.¶
Depending on the deployment model case, issuance may require some form ofClient anonymization service, similar to an IP-hiding proxy, so that Issuerscannot learn information about Clients. This can be provided by an explicitparticipant 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, ClientsSHOULD minimize or remove identifyinginformation where possible when invoking the issuance protocol.¶
Issuers are uniquely identifiable by all Clients with a consistentidentifier. In a web context, this identifier might be the Issuer hostname.Issuers maintain one or more configurations, including issuance key pairs, foruse in the issuance protocol. Each configuration is assumed to have a uniqueand 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;seeSection 6.2 for more considerations around configurationrotation. The Issuer Public Key for each active configuration is made availableto Origins and Clients for use in the issuance and redemption protocols.¶
Certain instantiations of the issuance protocol may permit public or privatemetadata to be cryptographically bound to a token. As an example, onetrivial way to include public metadata is to assign a unique IssuerPublic Key for each value of metadata, such that N keys yieldlog2(N) bits of metadata. Metadata may be public or private.¶
Public metadata is metadata that Clients can observe as part of the tokenissuance flow. Public metadata can be either transparent or opaque. Forexample, transparent public metadata is a value that either the Clientgenerates itself or the Issuer provides during the issuance flow and that theClient can check for correctness. Opaque public metadata is metadatathe Client can see but cannot check for correctness. As an example, theopaque public metadata might be a "fraud detection signal", computed onbehalf of the Issuer, during token issuance. Generally speaking, Clientscannot determine if this value is generated in a way that permits tracking.¶
Private metadata is metadata that Clients cannot observe as part of the tokenissuance flow. Such instantiations can be built on the private metadata bitconstruction 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 permittedmetadata may be determined by an application or by the underlying cryptographicprotocol. The total amount of metadata bits included in a token is the sum ofpublic and private metadata bits. Every bit of metadata can be used topartition the Client issuance or redemption anonymity sets; seeSection 6.1 for more information.¶
The Privacy Pass architecture and ecosystem are both intended to be receptiveto extensions that expand the current set of functionalities through newissuance protocols. Each new issuance protocol and extensionMUST adhereto the following requirements:¶
The end-to-end process of redemption and issuance protocols involves informationflowing between the Issuer, Origin, Client, and Attester. That information canhave implications on the privacy goals that Privacy Pass aims to provideas outlined inSection 3.3. In this section, we describe the flowof information between each party. How this information affects the privacygoals in particular deployment models is further discussed inSection 4.¶
To use Privacy Pass, Origins choose an Issuer from which they are willing toaccept tokens. Origins then construct a token challenge using this specifiedIssuer and information from the redemption context it shares with the Client.This token challenge is then delivered to a Client. The token challenge conveysinformation about the Issuer and the redemption context, such as whether theOrigin desires a per-Origin or cross-Origin token. Any entity that seesthe 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 itensures that the challenge is not directly available to the Issuer.¶
Clients interact with the Attester to prove that they meet some requiredset of properties. In doing so, Clients contribute information to theattestation context, which might include sensitive information such asapplication-layer identities, IP addresses, and so on. Clients can choosewhether or not to contribute this information based on local policy orpreference.¶
Clients use the issuance protocol to produce a token bound to a tokenchallenge. In doing so, there are several ways in which the issuance protocolcontributes information to the attestation or issuance contexts. For example, atoken request may contribute information to the attestation or issuancecontexts as described below.¶
Moreover, a token may contribute information to the issuance attestation orcontexts as described below.¶
Exceptional cases in the issuance protocol, such as when either theAttester or Issuer aborts the protocol, can contribute information to theattestation or issuance contexts. The extent to which information in thiscontext harms the Issuer-Client or Attester-Origin unlinkability goals as discussed inSection 3.3 depends on the deployment model; seeSection 4.Clients can choose whether or not to contribute information to these contextsbased on local policy or preference.¶
Clients send tokens to Origins during the redemption protocol. Any informationthat 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) implicitin the way the Client responds to a token challenge. For example, if a Clientfails to complete issuance and consequently fails to redeem a token fora token challenge, this can reveal information to the Origin thatit might not otherwise have access to. However, an Origin cannot necessarilydistinguish between a Client that fails to complete issuance and one thatignores the token challenge altogether.¶
The Origin, Attester, and Issuer portrayed inFigure 1 can beinstantiated and deployed in a number of ways. The deployment model directlyinfluences the manner in which attestation, issuance, and redemption contextsare separated to achieve Origin-Client, Issuer-Client, and Attester-Originunlinkability.¶
This section covers some expected deployment models and their correspondingsecurity and privacy considerations. Each deployment model is described interms of the trust relationships and communication patterns between the Client,Attester, Issuer, and Origin. Entities drawn within the same bounding box areassumed 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.¶
In this model, the Origin, Attester, and Issuer are all operated by the sameentity, as shown inFigure 3.¶
This model represents the initial deployment of Privacy Pass, as described in[PrivacyPassCloudflare]. In this model, the Attester, Issuer, and Originshare the attestation, issuance, and redemption contexts. As a result,attestation mechanisms that can uniquely identify a Client, e.g., requiringthat Clients authenticate with some type of application-layer account, arenot appropriate, as they could lead to unlinkability violations.¶
Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires thatissuance and redemption events be separated over time, such as through the useof tokens that correspond to token challenges with an empty redemption context(seeSection 3.4), or that they be separated over space, such as through the use of ananonymizing service when connecting to the Origin.¶
In this model, the Attester and Issuer are operated by the same entity,separate from the Origin. The Origin trusts the joint Attesterand Issuer to perform attestation and issue tokens. Clients interactwith the joint Attester and Issuer for attestation and issuance. Thisarrangement is shown inFigure 4.¶
This model is useful if an Origin wants to offload attestation and issuance toa trusted entity. In this model, the Attester and Issuer share an attestationand issuance context for the Client, separate from the Origin'sredemption context.¶
Similar to the shared Origin, Attester, Issuer model, Issuer-Client andOrigin-Client unlinkability in this model requires that issuance and redemptionevents, respectively, be separated over time or space. Attester-Originunlinkability requires that the Attester and Issuer do not learn the Originfor a particular token request. For this reason, issuance protocols thatrequire the Issuer to learn information about the Origin, such as the issuance protocol described in[RATE-LIMITED], are notappropriate, since they could lead to Attester-Origin unlinkability violationsthrough the Origin name.¶
In this model, the Origin and Issuer are operated by the same entity, separatefrom the Attester, as shown inFigure 5. The Issuer accepts tokenrequests that come from trusted Attesters. Since the Attester and Issuer areseparate entities, this model requires some mechanism by which Issuersestablish trust in the Attester (as described inSection 3.3).For example, in settings where the Attester is a Client-trusted service thatdirectly communicates with the Issuer, one way to establish this trust is viamutually authenticated TLS. However, alternative authentication mechanisms arepossible. In this model, the Origin and Issuer are operated by the same entity, separate from the Attester, as shown in the figure below.¶
This model is useful for Origins that require Client-identifying attestation,e.g., through the use of application-layer account information, but do nototherwise want to learn information about individual Clients beyond what isobserved during the token redemption, such as Client IP addresses.¶
In this model, attestation contexts are separate from Issuer and redemptioncontexts. 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 identifyingClient information and unique Origin information. Issuers that produce tokensfor a single Origin are not suitable in this model, since an Attester caninfer the Origin from a token request, as described inSection 3.6.3. However,since the issuance protocol provides input secrecy, the Attester does not learndetails about the corresponding token challenge, such as whether the tokenchallenge is per Origin or across Origins.¶
In this model, the Origin, Attester, and Issuer are all operated by differententities. As with the Joint Origin and Issuer model (Section 4.3), the Issuer accepts tokenrequests that come from trusted Attesters, and the details of that trustestablishment depend on the issuance protocol and relationship between theAttester and Issuer; seeSection 3.3. This arrangement is showninFigure 1.¶
This is the most general deployment model and is necessary for sometypes of issuance protocols where the Attester plays a role in tokenissuance; see[RATE-LIMITED] for one such type of issuance protocol.¶
In this model, the Attester, Issuer, and Origin have a separate viewof the Client: the Attester sees potentially sensitive Client-identifyinginformation, such as account identifiers or IP addresses; the Issuersees only the information necessary for issuance; and the Origin seestoken challenges, corresponding tokens, and Client source information,such as their IP address. As a result, attestation, issuance, and redemptioncontexts are separate, and therefore any type of token challenge is suitable inthis model as long as there is more than a single Origin.¶
As with the Joint Origin and Issuer model (Section 4.3), and asdescribed inSection 3.6.3, if the Issuer produces tokens for a single Origin,then per-Origin tokens are not appropriate, since the Attester can infer theOrigin from a token request.¶
Section 4 discusses deployment models that are possible in practice.Beyond possible implications on security and privacy properties of theresulting system, Privacy Pass deployments can impact the overall ecosystemin two important ways: (1) discriminatory treatment of Clients and the gatedaccess to otherwise open services and (2) centralization. This sectiondescribes considerations relevant to these topics.¶
Origins can use tokens as a signal for distinguishing between (1) Clientsthat are capable of completing attestation with one Attester trusted by theOrigin's chosen Issuer and (2) Clients that are not capable of doing the same. Aconsequence of this is that Privacy Pass could enable discriminatory treatmentof Clients based on attestation support. For example, an Origin could onlyauthorize Clients that successfully authenticate with a token, prohibiting accessto all other Clients.¶
The types of attestation procedures supported for a particular deployment dependgreatly on the use case. For example, consider a proprietary deployment of Privacy Passthat authorizes Clients to access a resource such as an anonymization service. In thiscontext, it is reasonable to support specific types of attestation procedures thatdemonstrate that Clients can access the resource, such as with an account or specifictype of device. However, in open deployments of Privacy Pass that are used tosafeguard access to otherwise open or publicly accessible resources, diversityin attestation procedures is critically important so as to not discriminate againstClients that choose certain software, hardware, or identity providers.¶
In principle, Issuers should strive to mitigate discriminatory behavior byproviding equitable access to all Clients. This can be done by working with aset of Attesters that are suitable for all Clients. In practice, this may requiretrade-offs in what type of attestation Issuers are willing to trust so as toenable more widespread support. In other words, trusting a variety of Attesterswith a diverse set of attestation procedures would presumably increase supportamong Clients, though most likely at the expense of decreasing the overall valueof tokens issued by the Issuer.¶
For example, to disallow discriminatory behavior between Clients with andwithout device attestation support, an Issuer may wish to support Attestersthat support CAPTCHA-based attestation. This means that the overall attestationvalue of a Privacy Pass token is bound by the difficulty in spoofing orbypassing either one of these attestation procedures.¶
A consequence of limiting the number of participants (Attesters or Issuers) inPrivacy Pass deployments for meaningful privacy is that it forces concentratedcentralization among those participants.[CENTRALIZATION] discussesseveral ways in which this might be mitigated. For example, a multi-stakeholdergovernance model could be established to determine what candidate participantsare fit to operate as participants in a Privacy Pass deployment. This isprecisely the system used to control the Web's trust model.¶
Alternatively, Privacy Pass deployments might mitigate this problem throughimplementation. For example, rather than centralize the role of attestationin one or a few entities, attestation could be a distributed function performedby a quorum of many parties, provided that neither Issuers nor Origins learnwhich Attester implementations were chosen. As a result, Clients could havemore opportunities to switch between attestation participants.¶
The previous section discusses the impact of deployment details onOrigin-Client, Issuer-Client, and Attester-Origin unlinkability.The value these properties afford to end users depends onthe size of anonymity sets in which Clients or Origins areunlinkable. For example, consider two different deployments, one whereinthere exists a redemption anonymity set of size two and anotherwherein there exists a redemption anonymity set of size 232. AlthoughOrigin-Client unlinkability guarantees that the Origin cannot link any tworequests to the same Client based on these contexts, respectively, thesmaller 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 setsmay be reduced or partitioned, though they all center around the concept ofconsistency. In particular, by definition, all Clients in an anonymity setshare a consistent view of information needed to run the issuance andredemption protocols. The Issuer Public Key is an example of the type of information needed to run these protocols. When two Clients have inconsistentinformation, these Clients effectively have different redemption contexts andtherefore 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 theunderlying problem.¶
Any public or private metadata bits of information can be used to furthersegment the size of the Client anonymity set. Any Issuer that wanted totrack a single Client could add a single metadata bit to Client tokens. Forthe tracked Client, it would set the bit to1, and0 otherwise. Addingadditional bits provides an exponential increase in tracking granularityin 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 Issuerin creating tokens, together with the bits of information that Issuers may learn about Clients through other means, into account. Since thismetadata may be useful for practical deployments of Privacy Pass, Issuersmust balance this against the reduction in Client privacy.¶
The number of permitted metadata values often depends on deployment-specificdetails. In general, limiting the amount of metadata permitted helps limit theextent to which metadata can uniquely identify individual Clients. Failure tobound the number of possible metadata values can therefore lead to a reduction inClient privacy. Most token types do not admit any metadata, so this bound isimplicitly enforced.¶
Anonymity sets can be partitioned by information used for the issuanceprotocol, including metadata, Issuer configuration (keys), and Issuerselection.¶
Any issuance metadata bits of information can be used to partition the Clientanonymity set. For example, any Issuer that wanted to track a single Clientcould add a single metadata bit to Client tokens. For the tracked Client, itwould set the bit to1, and0 otherwise. Adding additional bits provides anexponential increase in tracking granularity in a manner similar to introducing moreIssuers (though with more potential targeting).¶
The number of active Issuer configurations also contributes to anonymity setpartitioning. In particular, when an Issuer updates their configuration andthe corresponding key pair, any Client that invokes the issuance protocol withthis configuration becomes part of a set of Clients that also ran theissuance protocol using the same configuration. Issuer configuration updates,e.g., due to key rotation, are an important part of hedging against long-termprivate key compromise. In general, key rotations represent a trade-off betweenClient privacy and Issuer security. Therefore, it is important that keyrotations occur on a regular cycle to reduce the harm of an Issuer keycompromise.¶
Lastly, if Clients are willing to issue and redeem tokens from a large numberof Issuers for a specific Origin and that Origin accepts tokens from allIssuers, partitioning can occur. As an example, if a Client obtains tokens frommany Issuers and an Origin later challenges that Client for a token from eachIssuer, the Origin can learn information about the Client. This arrangementmight happen if Clients request tokens from different Issuers, each of whichhas different Attester preferences. Each per-Issuer token that a Client holdsessentially corresponds to a bit of information about the Client that the Originlearns. Therefore, there is an exponential loss in privacy relative to thenumber of Issuers.¶
The fundamental problem here is that the number of possible issuanceconfigurations, including the keys in use and the Issuer identities themselves,can partition the Client anonymity set. To mitigate this problem, ClientsSHOULD bound the number of active issuance configurations per Origin as well asacross Origins. Moreover, ClientsSHOULD employ some form of consistencymechanism to ensure that they receive the same configuration information andare not being actively partitioned into smaller anonymity sets. See[CONSISTENCY] for possible consistencymechanisms. Depending on the deployment, the Attester might assist the Clientin applying these consistency checks across Clients. Failure to apply aconsistency check can allow Client-specific keys to violate Origin-Clientunlinkability.¶
Side-channel attacks, such as those based on timing correlation, could beused to reduce anonymity set size. In particular,for interactive tokens that are bound to a Client-specific redemptioncontext, the anonymity set of Clients during the issuance protocol consistsof those Clients that started issuance between the time of the Origin'schallenge and the corresponding token redemption. Depending on the numberof Clients using a particular Issuer during that time window, the set canbe small. Applications should take such side channels into consideration beforechoosing a particular deployment model and type of token challenge andredemption context.¶
This document describes security and privacy requirements for the Privacy Passredemption and issuance protocols. It also describes deployment models builtaround non-collusion assumptions and privacy considerations for using PrivacyPass within those models. Ensuring Client privacy -- separation of attestationand redemption contexts -- requires active work on behalf of the Client,especially in the presence of malicious Issuers and Origins. Implementing themitigations discussed in Sections 4 and6 is therefore necessaryto ensure that Privacy Pass offers meaningful privacy improvements to end users.¶
Depending on the Origin's token challenge, Clients can request and cache morethan one token using an issuance protocol. Cached tokens help improve privacy byseparating the time of token issuance from the time of token redemption; theyalso allow Clients to reduce the overhead of receiving new tokens via theissuance protocol.¶
As a consequence, Origins that send token challenges that are compatible withcached 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 theperiod of time in which cached tokens would be accepted for particularchallenges.¶
Moreover, since tokens are not intrinsically bound to Clients, it is possiblefor malicious Clients to collude and share tokens in a so-called "hoardingattack". As an example of this attack, many distributed Clients could obtaincacheable tokens and then share them with a single Client to redeem the tokens in a waythat would violate an Origin's attempt to limit tokens to any one particularClient. In general, mechanisms for mitigating hoarding attacks depend on thedeployment 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 thedistribution of issuance contexts. Rate-limiting issuance, at either the Client,Attester, or Issuer, can also help mitigate these attacks.¶
This document has no IANA actions.¶
The authors would like to thankEric Kinnear,Scott Hendrickson,Tommy Pauly,Christopher Patton,Benjamin Schwartz,Martin Thomson,Steven Valdez, and othercontributors of the Privacy Pass Working Group for many helpful contributionsto this document.¶