Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 I should have stacked PRs , but these issues were small enough to address that I just threw them into separate commits here . Sorry , 
 The abstract does n't really reveal what the document is doing . I found this statement near the end of the introduction more useful : protocols . This document also describes ecosystem considerations that impact the stated privacy and security guarantees of the protocol . 
 I think this protocol is not specific to HTTP . If that 's the case , the use of ' cross - origin ' before the defintion of ' Origin ' ( as well as the difference in case ) might confuse some readers , especially those familiar with the Web . 
 I think this document could be titled or ... but I 'm not sure that " Privacy Pass Architectural Framework " is called for ... 
 The start of s.6 states : Then the Token exhaustion refers to a " malicious verifier " who can force a client into spending tokens : I 'm not sure who the " verifier " is . ( See . As far as I can tell ,  and  are the only places that the term " verifier " is used . ) In any case , I would suggest reconciling the " malicious  " with the " malicious verifier " who forces the Client into spending tokens . As is , the threat model is a bit unclear , at least to me . 
 It 's not clear from context ( to me , at least ) who the verifier is here . I suppose the Origin ? If so , I 'd suggest replacing " verifier " with " Origin " . Similar question for  . 
 I 'm not sure how to interpret the following : What is meant the " distribution of Issuer trust " here ? Relatedly , can you explain the math here : My understanding is that the set of users can be partitioned into 2 ^ 4 = 16 different sets ( not 64 ) . More than likely I 'm missing something obvious . Either way , this seems like a reasonably conservative recommendation . ( It 's hard for me to imagine more than a handful of Issuers being active in a deployment . ) 
 Yeah , this was really unclear , mostly because it was left over from a prior version of the document . I tried to consolidate and clarify the text in this section ( and its subsections ) to improve the situation . Please have a look at for the proposed change ! 
 Sometimes " Issuance protocol " is written , other times it reads " issuance protocol " . ( Similarly for " cross - Origin " . ) Which is preferred ? Is consistency a concern ? 
 The keyword SHOULD is used in this document to suggest considerations for PP deployments . These kinds of considerations are also mentioned in this section , but w/o SHOULD . For example : This should could be SHOULD , I think . ( Sorry for the nightmare of a sentence that was . ) Similarly here : If this is important ( perhaps not ? ) it might be worth going through the rest of the document to check for consistency . 
 If I understand correctly , there may be a many - to - one relationship between Attesters and Issuers . Is that right ? If so , it might be worth refining . ( I would also say there might be many Issuers , as there might be a many - to - one relationship between Clients and Issuers as well . ) 
 I 'm not sure what " cross - origin " means in this context . ( I am not an HTTP expert , ) " Cross - origin token " is used in the next paragraph . Is that what 's meant here ? EDIT : After reading more of the draft , it sounds like " cross - origin token " is indeed what 's meant . However I 'm not sure if this is ever clearly defined . Is a cross - origin token one that can be redeemed by multiple origins ? 
 Section 5.2 states : window for Clients to participate in the issuance protocol and thus enjoy the anonymity guarantees of being part of a larger group . A maximum of 12 weeks limits the damage caused by a key compromise . If an Issuer realizes that a key compromise has occurred then the Issuer should generate a new key and make it available to Clients . If possible , it should invoke any revocation procedures that may apply for the old key . Is this 1 - 12 week recommendation really universally applicable , or should an implementor / deployer take into account the number and frequency of client interactions ? It seems like the real goal is the size of the anonymity set , not the number of days ( modulo risk of key compromise ) . For example , if there 's a system that only has 10 clients a week , would it make sense to use a longer value ? 
 Great catch . We should just remove this recommendation and describe the tradeoff more clearly ( which is somewhat done ) . 
 Section 3.2 states : of the protocol , why these impacts are justified , and guidelines on how to deploy the protocol to minimize any privacy impacts . However , Section 3.2.4 states : privacy impacts of the extension , why these impacts are justified , and guidelines on how to deploy the protocol to minimize any privacy impacts . ( After editorial nits are resolved in each section ) This likely should be consistent everywhere , or even just left to the explicit extensibility section ( 3.2.4 ) and referenced from 3.2 . 
 Nit : Section 3 contains quite a few places where 2119 keywords are used uncapitalized , which can be fine , but there are enough of them that it might be worth doing a quick pass to make sure that 's all intentional . For example : which was proceeded by : All three of these requirements seem rather equally important , and while normative text does n't need to use capitalized 2119 keywords , I 'm assuming there was n't intentionally any significance to the difference in their use between those paragraphs . 
 I do n't think they 're really enforceable , so moving away from 2119 language seems best here . 
 A minor nit , but it was a little odd leaving the abstract / introduction which was very focused on Issue / Attest then Redemption to have 3.1 be the Redemption protocol in reverse order . Is it possible to just move text around in the Introduction so that it 's all consistent ? This could also potentially be a nice moment to reconcile the diagram in the introduction : with the one in 3.2 : Notably , is under  in one but under Attester in the other and the token response -token flow is subtly different , although it would appear that 's not intentionally conveying a difference in meaning . 
 In the introduction , client is capitalized for the first time here : despite having been used in the proceeding paragraphs to help illustrate the overall goals of Privacy Pass . I 'm assuming that 's intentional as it transitions from colloquial use of " client " to the formally defined " Client " , perhaps that should be made clear , something like : or Perhaps more importantly , how is it that runs between an endpoint ( Client ) and a " network function " described as one of Attestation and Issuance ? I kind of expected issuance to run between a and ( Issuer ? ) for the purposes of issuance , not attestation . Later on , this proves true via Issuer / Attester , so perhaps worth updating the introduction to match . This may just be fallout of having a structure like so : Likely solvable via some light editorial tweaks in the introduction , but also wanted to note that it might be worth just presenting it as a single flat layer : , , and , where the Issuer and Attester might be the same entity and the  is involved for Redemption . Could simplify things , and that seems to match how the rest of the document handles it . 
 Section 3.2.1 has this : It may be good to have a reference to Section 4 about what the split deployment model is . Potentially useful in more parts of 3.2 as well . 
 I 'm not sure I follow what this is saying . Does it intend to say " resources protected with tokens " ? It also seems like a hard thing to enforce normatively without being more clear . 
 Removing this sentence altogether seems best . We already say that origins bear risk in accepting cross - origin tokens issued by interactions with other origins . 
  is defined currently as : I wonder if it may be better to say that the  is fundamentally the entity that redeems tokens presented by Clients ( and can challenge them too ) . 
 Similarly , in the " Redemption Protocol " section , we may want to mention that a client could just present a token auth without a challenge if it knows it will need it ahead of time . 
 The  says this : It also says this : It may be clearer to not call Privacy Pass both " a protocol " and " two protocols " . Either we call issuance and redemption " sub - protocols " , or we call the main thing " a mechanism " , " an architecture " , or " a set of protocols " . I kinda lean towards the last option . 
 Had the same thought while reading the introduction , in the abstract it is referred to as an , so perhaps just : or just a " set of protocols " would work nicely too .
This document specifies the architectural framework for constructing
secure and anonymity-preserving instantiations of the Privacy Pass
protocol.  It provides recommendations on how the protocol ecosystem
should be constructed to ensure the privacy of clients and the
security of all participating entities.
Privacy Pass is a protocol for authorization based on anonymous-
credential authentication mechanisms.  Typical approaches for
authorizing clients, such as through the use of long-term 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., whether or not the client is an authorized user or
has completed some prior challenge, clients present unlinkable proofs
that attest to this information.
The most basic Privacy Pass protocol provides a set of cross-origin
authorization tokens that protect the Clients' anonymity during
interactions with a server.  This allows clients to communicate an
attestation of a previously authenticated server action without
having to reauthenticate manually.  The tokens retain anonymity in
the sense that posession of a token cannot be linked to the session
in which that token was initially issued.
At a high level, Privacy Pass is composed of two protocols: issuance
and redemption.
The issuance protocol runs between a Client and two network functions
in the Privacy Pass architecture: Attestation and Issuance.  These
two network functions can be implemented by the same protocol
participant, but can also be implemented separately.  The Issuer is
responsible for issuing tokens in response to requests from Clients.
The Attester is responsible for attesting to properties about the
Client for which tokens are issued.  The Issuer needs to be trusted
by the server that later redeems the token.  Attestation can be
performed by the Issuer or by an Attester that is trusted by the
Issuer.  Clients might prefer to select different Attesters, separate
from the Issuer, to be able to use preferred authentication methods
or to improve privacy by not directly communicating with an Issuer.
Depending on the attestation, Attesters can store state about a
Client, such as the number of overall tokens issued thus far.  As an
example of an Issuance protocol, in the original Privacy Pass
protocol PPSRV, tokens were only issued to Clients that solved
CAPTCHAs.  In this context, the Attester attested that some client
solved a CAPTCHA and the resulting token produced by the Issuer was
proof of this fact.
The redemption protocol runs between Client and Origin (server).  It
allows Origins to challenge Clients to present one or more tokens for
authorization.  Depending on the type of token, e.g., whether or not
it is cross-origin or per-origin, and whether or not it can be
cached, the Client either presents a previously obtained token or
invokes the issuance protocol to acquire one for authorization.
This document describes requirements for both issuance and redemption
protocols.  This document also describes ecosystem considerations
that impact the stated privacy and security guarantees of the
protocol.
This document specifies the Privacy Pass architecture and
requirements for its constituent protocols used for constructing
anonymous-credential authentication mechanisms.  It provides
recommendations on how the architecture should be deployed to ensure
the privacy of clients and the security of all participating
entities.
Privacy Pass is an architecture for authorization based on anonymous-
credential authentication mechanisms.  Typical approaches for
authorizing clients, such as through the use of long-term 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 anonymous in the sense that a given token
cannot be linked to the protocol instance in which that token was
initially issued.
At a high level, the Privacy Pass architecture consists of two
protocols: issuance and redemption.  The issuance protocol runs
between an endpoint referred to as a Client and two functions in the
Privacy Pass architecture: Attestation and Issuance.  These two
network functions can be implemented by the same protocol
participant, but can also be implemented separately.  The entity that
implements Issuance, referred to as the Issuer, is responsible for
issuing tokens in response to requests from Clients.  The entity that
implements Attestation, referred to as the Attester, is responsible
for attesting to properties about the Client for which tokens are
issued.  The Issuer needs to be trusted by the server that later
redeems the token.  Attestation can be performed by the Issuer or by
an Attester that is trusted by the Issuer.  Clients might prefer to
select different Attesters, separate from the Issuer, to be able to
use preferred authentication methods or to improve privacy by not
directly communicating with an Issuer.  Depending on the attestation,
Attesters can store state about a Client, such as the number of
overall tokens issued thus far.  As an example of an issuance
protocol, in the original Privacy Pass protocol PPSRV, tokens were
only issued to Clients that solved CAPTCHAs.  In this context, the
Attester attested that some client solved a CAPTCHA and the resulting
token produced by the Issuer was proof of this fact.
The redemption protocol runs between Client and Origin (server).  It
allows Origins to challenge Clients to present one or more tokens for
authorization.  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 the issuance protocol to acquire one for
authorization.
This document describes requirements for both issuance and redemption
protocols.  It also provides recommendations on how the architecture
should be deployed to ensure the privacy of clients and the security
of all participating entities.
Origin: An entity that challenges Clients for tokens.
Origin: An entity that redeems tokens presented by Clients.
The redemption protocol is a simple challenge-response based
authorization protocol between Client and Origin.  Origins prompt
Clients with a token challenge and, if possible, Clients present a
valid token for the challenge in response.  The context in which an
Origin challenges a Client for a token is referred to as the
redemption context.  This context includes all information associated
with the redemption event, such as the timestamp of the event, Client
visible information (including the IP address), and the Origin name.
The redemption protocol is an authorization protocol wherein Clients
present tokens to Origins for authorization.  Normally, redemption
follows a challenge-response flow, wherein the Origin challenges
Clients for a token and, if possible, Clients present a valid token
for the challenge in response.  Alternatively, when configured to do
so, Clients may opportunistically present tokens to Origins without a
corresponding challenge.
The context in which an Origin challenges a Client for a token is
referred to as the redemption context.  This context includes all
information associated with the redemption event, such as the
timestamp of the event, Client visible information (including the IP
address), and the Origin name.
Per-origin or cross-origin.  Tokens can be constrained to the
Origin for which the challenge originated, or can be used across
Origins.
Depending on the use case, Origins may need to maintain state to
track redeemed tokens.  For example, Origins that accept cross-origin
across shared redemption contexts tokens SHOULD track which tokens
have been redeemed already in those redemption contexts, since these
tokens can be issued and then spent multiple times in response to any
such challenge.  See Section 2.1.1 of HTTP-Authentication for
discussion.
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.  If tokens protected with resources are unique to a
single Origin, then said Origin MUST NOT admit cross-origin tokens
for authorization.
Per-Origin or cross-Origin.  Tokens 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.
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, 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 been redeemed already in
those redemption contexts, since these tokens can be issued and then
spent multiple times in response to any such challenge.  See
Section 2.1.1 of HTTP-Authentication for discussion.
Concurrent security.  The issuance protocol MUST be safe to run
concurrently with arbitrarily many Clients.
Each Issuance protocol MUST include a detailed analysis of the
privacy impacts of the protocol, why these impacts are justified, and
guidelines on how to deploy the protocol to minimize any privacy
impacts.
Concurrent security.  The issuance protocol MUST be safe to run
concurrently with arbitrarily many Clients, Attesters and Issuers.
See extensions for requirements on new issuance protocol variants and
related extensions.
Each of these attestation types has different security properties.
For example, attesting to having a valid account is different from
attesting to running on trusted hardware.  In general, Attesters
should accept a limited form of attestation formats.
Each of these attestation types has different security properties.
For example, attesting to having a valid account is different from
attesting to running on trusted hardware.  In general, minimizing the
set of attestation formats helps minimize the amount of information
leaked through a token.
To facilitate issuance, the Issuer MUST hold an Issuance key pair at
any given time.  The Issuer public key MUST be made available to all
Clients in such a way that key rotations and other updates are
publicly visible.  The key material and protocol configuration that
an Issuer uses to produce tokens corresponds to two different pieces
of information.
Issuers maintain an issuance key pair for the issuance protocol.  The
Issuer public key is made available to all Clients in such a way that
key rotations and other updates are publicly visible.  The key
material and protocol configuration that an Issuer uses to produce
tokens corresponds to two different pieces of information.
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 issuance
protocol SHOULD include a detailed analysis of the privacy impacts of
the extension, why these impacts are justified, and guidelines on how
to deploy the protocol to minimize any privacy impacts.  Any
extension to the Privacy Pass protocol MUST adhere to the guidelines
specified in issuer-role for managing Issuer public key data.
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 issuance
protocol MUST include a detailed analysis of the privacy impacts of
the extension, why these impacts are justified, and guidelines on how
to deploy the protocol to minimize any privacy impacts.  Any
extension to the Privacy Pass protocol MUST adhere to the guidelines
specified in issuer-role for managing Issuer public key data.
In the following, we consider the possible ways that Issuers can
leverage their position to try and reduce the size of the anonymity
sets to which Clients belong, often by segregating users.  For each
case, we provide mitigations that the Privacy Pass ecosystem must
implement to prevent these actions.
In the following, we consider the possible ways that Issuers can
leverage their position to try and reduce the size of the anonymity
sets to which Clients belong, often by segregating Clients.  For each
case, we provide mitigations that the Privacy Pass ecosystem must
implement to prevent these actions.
For this reason, the amount of metadata used by an Issuer in creating
redemption tokens must be taken into account - together with the bits
of information that Issuers may learn about Clients otherwise.  Since
this metadata may be useful for practical deployments of Privacy
Pass, Issuers must balance this against the reduction in Client
privacy.  In general, Issuers should bound the metadata permitted so
as to not allow it to uniquely identify each possible user.
Techniques to introduce Client "segregation" can be used to reduce
Client anonymity.  Such techniques are closely linked to the type of
key schedule that is used by the Issuer.  When an Issuer rotates
their key, any Client that invokes the issuance protocol in this key
cycle will be part of a group of possible Clients owning valid tokens
for this key.  To mechanize this attack strategy, an Issuer could
introduce a key rotation policy that forces Clients into small key
cycles, reducing the size of the anonymity set for these Clients.
Issuers SHOULD invoke key rotation for a period of time between 1 and
12 weeks.  Key rotations represent a trade-off between Client privacy
and continued Issuer security.  Therefore, it is still important that
key rotations occur on a regular cycle to reduce the harmfulness of
an Issuer key compromise.
For this reason, the amount of metadata used by an Issuer in creating
redemption tokens must be taken into account - together with the bits
of information that Issuers may learn about Clients otherwise.  Since
this metadata may be useful for practical deployments of Privacy
Pass, Issuers must balance this against the reduction in Client
privacy.  In general, bounding the metadata permitted ensures that it
cannot uniquely identify individual Clients.
Issuer key rotation is important to hedge against long-term private
key compromise.  However, key rotation can also be used to segment
Client anonymity sets.  In particular, when an Issuer rotates their
key, any Client that invokes the issuance protocol in this key cycle
will be part of a group of possible Clients owning valid tokens for
this key.  To mechanize this attack strategy, an Issuer could
introduce a key rotation policy that forces Clients into small key
cycles, reducing the size of the anonymity set for these Clients.
In general, key rotations represent a trade-off between Client
privacy and continued Issuer security.  Therefore, it is still
important that key rotations occur on a regular cycle to reduce the
harmfulness of an Issuer key compromise.
Similarly to the Issuer rotation dynamic discussed above, if there
are a large number of Issuers, and Origins accept all of them,
segregation can occur.  If Clients obtain tokens from many Issuers,
and Origins later challenge a Client for a token from each Issuer,
Origins can learn information about the Client.  Each per-Issuer
token that a Client holds essentially corresponds to a bit of
information about the Client that Origin learns.  Therefore, there is
an exponential loss in anonymity relative to the number of Issuers
that there are.
For example, if there are 32 Issuers, then Origins learn 32 bits of
information about the Client if a valid token is presented for each
Issuer.  If the distribution of Issuer trust is anything close to a
uniform distribution, then this is likely to uniquely identify any
Client amongst all other Internet users.  Assuming a uniform
distribution is clearly the worst-case scenario, and is unlikely to
be accurate, but it provides a stark warning against allowing too
many Issuers at any one time.
In cases where clients can hold tokens for all Issuers at any given
time, a strict bound SHOULD be applied to the active number of
Issuers in the ecosystem.  We propose that allowing no more than 4
Issuers at any one time is highly preferable (leading to a maximum of
64 possible user segregations).  However, having a very large user
base could potentially allow for larger values.  Issuer replacements
should only occur with the same frequency as config rotations as they
can lead to similar losses in anonymity if clients still hold
redemption tokens for previously active Issuers.
In addition, we RECOMMEND that trusted registries indicate at all
times which Issuers are deemed to be active.  If a Client is asked to
invoke any Privacy Pass exchange for an Issuer that is not declared
active, then the client SHOULD refuse to retrieve the Issuer public
key during the protocol.
The bounds on the numbers of Issuers that this document proposes
above are very restrictive.  This is because this document considers
a situation where a Client could be challenged (and asked to redeem)
tokens for any Issuer.
An alternative system is to ensure a robust strategy for ensuring
that Clients only possess redemption tokens for a similarly small
number of Issuers at any one time.  This prevents a malicious
verifier from being able to invoke redemptions for many Issuers since
the Client would only be holding redemption tokens for a small set of
Issuers.  When a Client is issued tokens from a new Issuer and
already has tokens from the maximum number of Issuers, it simply
deletes the oldest set of redemption tokens in storage and then
stores the newly acquired tokens.
For example, if Clients ensure that they only hold redemption tokens
for 4 Issuers, then this increases the potential size of the
anonymity sets that the Client belongs to.  However, this doesn't
protect Clients completely as it would if only 4 Issuers were
permitted across the whole system.  For example, these 4 Issuers
could be different for each Client.  Therefore, the selection of
Issuers for which a Client possesses tokens is still revealing.
Understanding this trade-off is important in deciding the effective
anonymity of each Client in the system.
Similarly to the Issuer rotation dynamic discussed above, if there
are a large number of Issuers, and Origins accept all of them,
segregation can occur.  If Clients obtain tokens from many Issuers,
and Origins later challenge a Client for a token from each Issuer,
Origins can learn information about the Client.  Each per-Issuer
token that a Client holds essentially corresponds to a bit of
information about the Client that Origin learns.  Therefore, there is
an exponential loss in anonymity relative to the number of Issuers.
For example, if there are 32 Issuers, then Origins learn 32 bits of
information about the Client if a valid token is presented for each
Issuer.  As a contrasting example, if Clients ensure that they only
hold tokens issued from 4 Issuers, then this increases the potential
size of the anonymity sets that the Client belongs to.  However, this
doesn't protect Clients completely as it would if only 4 Issuers were
permitted across the whole system.  For example, these 4 Issuers
could be different for each Client.  Therefore, the selection of
Issuers for which a Client possesses tokens is still revealing.  This
trade-off is important in deciding the effective anonymity of each
Client in the system.
Clients SHOULD bound the number of Issuers they are willing to
request tokens from at any given time.  The exact bound depends on
the deployment model and number of Clients, i.e., having a very large
Client base could potentially allow for larger values.  Issuer
replacements should only occur with the same frequency as config
rotations as they can lead to similar losses in anonymity if clients
still hold redemption tokens for previously active Issuers.
Alternatively, when applicable, trusted registries can indicate which
Issuers are deemed to be active.  If a Client is asked to invoke the
issuance protocol for an Issuer that is not declared active, then the
client can refuse to run the protocol and obtain a token.
the verifier can learn is bounded by the number of "redemption
partitions".
the Origin can learn is bounded by the number of "redemption
partitions".
Beyond the aforementioned security gaols for the Issuance protocol
(issuance-protocol), it is important for Privacy Pass deployments to
mitigate the risk of abuse by malicious Clients.
When a Client holds tokens for an Issuer, it is possible for any
verifier to cause that client to redeem tokens for that Issuer.  This
can lead to an attack where a malicious verifier can force a Client
to spend all of their tokens from a given Issuer.  To prevent this
from happening, tokens can be scoped to single Origins such that they
can only be redeemed for a single Origin.
Beyond the aforementioned security goals for the issuance protocol
(issuance-protocol), it is important for Privacy Pass deployments to
mitigate the risk of abuse by malicious Origins.