Draft: draft-ietf-privacypass-architecture

Commentary: cc 
 In the architecture document , we should have more discussion of correlation attacks and ways to mitigate . For example , interactive vs non - interactive tokens can making timing correlation attacks more or less relevant . For mitigations , the deployment model of issuer / origin ( and attester ) can make a difference .
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.
Per-domain or cross-domain.  Tokens can be constrained to the
Origin for which the challenge originated, or can be used across
Origins.
Per-origin or cross-origin.  Tokens can be constrained to the
Origin for which the challenge originated, or can be used across
Origins.
Clients interact with the Attester and Issuer to produce a token in
response to 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.
Unconditional input secrecy.  The issuance protocol MUST NOT
reveal anything about the Client's private input, including the
challenge and nonce.  The issuance protocol can reveal the Issuer
public key for the purposes of determining which private key to
use in producing the issuance protocol.  A result of this property
is that the redemption flow is unlinkable from the issuance flow.
One-more forgery security.  The issuance protocol MUST NOT allow
malicious Clients to forge tokens without interacting with the
Issuer directly.
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.  The issuance
protocol can reveal the Issuer public key for the purposes of
determining which private key to use in producing the issuance
protocol.  A result of this property is that the redemption flow
is unlinkable from the issuance flow.
One-more forgery security.  The issuance protocol MUST NOT allow
malicious Clients or Attesters (acting as Clients) to forge tokens
without interacting with the Issuer directly.
The goal of the Privacy Pass ecosystem is to construct an environment
that can easily measure and maximize the relative anonymity of any
Client that is part of it.  An inherent feature of being part of this
ecosystem is that any Client can only remain private relative to the
entire space of users using the protocol.  Moreover, by owning tokens
for a given set of keys, the Client's anonymity set shrinks to the
total number of clients controlling tokens for the same keys.
Client uses Privacy Pass to separate attestation context and
redemption context.  Linking or combining these contexts can reveal
sensitive information about the Client, including their identity or
browsing history.  Depending on the deployment model, separating
these contexts can take different forms.  The Origin, Attester, and
Issuer portrayed in fig-overview can be instantiated and deployed in
a number of different ways.  This section covers some expected
deployment models and their corresponding security and privacy
considerations.  The discussion below assumes non-collusion between
entities when operated by separate parties.  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 same entity, as shown in the figure below.
This model represents the initial deployment of Privacy Pass, as
described in PPSRV.  In this model, the Attester, Issuer, and Origin
share the attestation 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 be used to learn or
reconstruct a Client's browsing history.
Attestation and redemption context unlinkability requires that these
events be separated over time, e.g., through the use of non-
interactive tokens that can be issued without a fresh Origin
challenge, or over space, e.g., through the use of an anonymizing
proxy when connecting to the Origin.
In this model, the Attester and Issuer are operated by the same
entity that is separate from the Origin, as shown in the figure
below.
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 attestation context for the Client, which can be separate from
the Origin's redemption context.
For certain types of issuance protocols, this model separates
attestation and redemption contexts.  However, Issuance protocols
that require the Issuer to learn information about the Origin, such
as that which is described in [rate-limited], are not appropriate
since they could link attestation and redemption contexts through the
Origin name.
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 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, the Origin, Attester, and Issuer are all operated by
different entities, as shown in the figure below.
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 and
redemption contexts are separate, and therefore any type of token
challenge is suitable in this model assuming there is more than a
single Origin.  As in the Joint Origin and Issuer model in deploy-
joint-origin, if there is only a single Origin, then per-Origin
tokens are not appropriate.
Client uses Private Pass to separate attestation context and
redemption context.  Depending on the deployment model, this can take
different forms.  For example, any Client can only remain private
relative to the entire space of other Clients using the protocol.
Moreover, by owning tokens for a given set of keys, the Client's
anonymity set shrinks to the total number of clients controlling
tokens for the same keys.
Similarly to the Issuer rotation dynamic that is raised above, if
there are a large number of Issuers and Origins accept all of them
segregation can occur.  For example, 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 learn.  Therefore, there
is an exponential loss in anonymity relative to the number of Issuers
that there are.
Similarly to the Issuer rotation dynamic that is raised above, if
there are a large number of Issuers, and Origins accept all of them,
segregation can occur.  For example, 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 learn.  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 learns 32 bits of
information about the Client.  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 unlikely to be accurate, but it provides a stark warning against
allowing too many Issuers at any one time.
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
one.  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 unlikely to be
accurate, but it provides a stark warning against allowing too many
Issuers at any one time.
The bounds on the numbers of Issuers that this document proposes
above are very restrictive.  This is due to the fact that this
document considers a situation where a Client could be issued (and
forced to redeem) tokens for any Issuer.
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.
Another option to allow a large number of Issuers in the ecosystem,
while preventing the joining of a number of different tokens is for
the Client to maintain sharded "redemption contexts".  This would
allow the Client to redeem the tokens it wishes to use in a
particular context, while still allowing the Client to maintain a
large variety of tokens from many Issuers.  Within a redemption
context, the Client limits the number of different Issuers used to a
small number to maintain the privacy properties the Client requires.
As long as each redemption context maintains a strong privacy
boundary with each other, the verifier will only be able to learn a
number of bits of information up to the limits within that
"redemption context".
If there are multiple key registries, or if a key registry colludes
with an Issuer, then it is possible to provide a split-view of an
Issuer's key material to different Clients.  This would involve
posting different key material in different locations, or actively
modifying the key material at a given location.
Key registries should operate independently of Issuers in the
ecosystem, and within the guidelines stated in issuer-role.  Any
Client should follow the recommendations in privacy for determining
whether an Issuer and its key material should be trusted.
Privacy losses may be encountered if too many redemptions are allowed
in a short burst.  For instance, in the Internet setting, this may
allow Origins to learn more information from the metadata that the
Client may hold (such as first-party cookies for other origins).
Mitigations for this issue are similar to those proposed in servers
for tackling the problem of having large number of Issuers.
Clients may see an incentive in accepting all tokens that are issued
by an Issuer, even if the tokens fail later verification checks.
This is because tokens effectively represent a form of currency that
they can later redeem for some sort of benefit.  The verification
checks that are put in place are there to ensure that the Client does
not sacrifice their anonymity.  However, a Client may judge the
"monetary" benefit of owning tokens to be greater than their own
privacy.
Firstly, a Client behaving in this way would not be compliant with
the protocol, as laid out in I-D.ietf-privacypass-protocol.
Secondly, acting in this way only affects the privacy of the
immediate Client.  There is an exception if a large number of Clients
colluded to accept bad data, then any Client that didn't accept would
be part of a smaller anonymity set.  However, such a situation would
be identical to the situation where the total number of Clients in
the ecosystem is small.  Therefore, the reduction in the size of the
anonymity set would be equivalent; see servers for more details.
Another option to allow a large number of Issuers in the ecosystem,
while preventing the joining of a number of different tokens is for
the Client to maintain sharded "redemption partitions".  This would
allow the Client to redeem the tokens it wishes to use in a
particular context, while still allowing the Client to maintain a
large variety of tokens from many Issuers.  Within a redemption
partition, the Client limits the number of different Issuers used to
a small number to maintain the privacy properties the Client
requires.  As long as each redemption partition maintains a strong
privacy boundary with each other, the verifier will only be able to
learn a number of bits of information up to the limits within that
"redemption partitions".
This section provides a summary of the parameters that used in the
Privacy Pass protocol ecosystem.  These parameters are informed by
both privacy and security considerations that are highlighted in
privacy and security, respectively.  These parameters are intended as
a single reference point for those implementing the protocol.
This section provides a summary of the parameters used in the Privacy
Pass protocol ecosystem.  These parameters are informed by both
privacy and security considerations that are highlighted in privacy
and security, respectively.  These parameters are intended as a
single reference point for those implementing the protocol.