Draft: draft-davidson-pp-protocol

Commentary: Issuer -Server Decapitalize ( client / server ) Message -Request cc I think we should be in okay shape to submit new drafts following these changes .
Issuer: A service that provides the server-side functionality
required by the protocol.  May also be known as the Server.
Server: A service that provides the server-side functionality
required by the protocol.  May be referred to as the issuer.
At any one time, we assume that the Issuer uses only one
configuration containing their ciphersuite choice along with their
secret key data.  This ensures that all Clients are issued tokens
under the single key associated with any given epoch.
We assume that the client has access to a global directory of the
current public parts of the configurations used the Issuer.
At any one time, we assume that the server uses only one
configuration containing their ciphersuite choice along with their
secret key data.  This ensures that all clients are issued tokens
under the single key associated with any given epoch.
We assume that the client has access to a global directory of the
current public parts of the configurations used the server.
Before the protocol takes place, the Issuer chooses a ciphersuite and
generates a keypair by running "(pkI, skI) = KeyGen()".  This
configuration must be available to all Clients that interact with the
Issuer (for the purpose of engaging in a Privacy Pass exchange).  We
assume that the Issuer has a public (and unique) identity that the
Client uses to retrieve this configuration.
The Client initialises a global storage system "store" that allows it
store the tokens that are received during issuance.  The storage
system is a map of Issuer identifiers ("Issuer.id") to arrays of
stored tokens.  We assume that the client knows the Issuer public key
"pkI" ahead of time.  The Client picks a value "m" of tokens to
receive during the issuance phase.  In draft-davidson-pp-architecture
we discuss mechanisms that the Client can use to ensure that this
public key is consistent across the entire ecosystem.
The issuance phase allows the Client to receive "m" anonymous
authorization tokens from the Issuer.
Before the protocol takes place, the server chooses a ciphersuite and
generates a keypair by running "(pkS, skS) = KeyGen()".  This
configuration must be available to all clients that interact with the
server (for the purpose of engaging in a Privacy Pass exchange).  We
assume that the server has a public (and unique) identity that the
client uses to retrieve this configuration.
The client initialises a global storage system "store" that allows it
store the tokens that are received during issuance.  The storage
system is a map of server identifiers ("server.id") to arrays of
stored tokens.  We assume that the client knows the server public key
"pkS" ahead of time.  The client picks a value "m" of tokens to
receive during the issuance phase.  In draft-davidson-pp-architecture
we discuss mechanisms that the client can use to ensure that this
public key is consistent across the entire ecosystem.
The issuance phase allows the client to receive "m" anonymous
authorization tokens from the server.
To protect against clients that attempt to spend a value "msg.data"
more than once, the server uses an index, "dsIdx", to collect valid
inputs it witnesses.  Since this store needs to only be optimized for
storage and querying, a structure such as a Bloom filter suffices.
The storage should be parameterized to live as long as the Issuer
keypair that is in use.  See sec-reqs for more details.
To protect against clients that attempt to spend a value "req.data"
more than once, the server uses an index, "dsIdx", to collect valid
inputs it witnesses.  Since this store needs to only be optimized for
storage and querying, a structure such as a Bloom filter suffices.
The storage should be parameterized to live as long as the server
keypair that is in use.  See sec-reqs for more details.
We use the following types to describe the public and private keys
used by the Issuer.
We use the following types to describe the public and private keys
used by the server.
Note that a "IssuanceInput" contains equal-length arrays of
"Internal" and "IssuanceMessage" types corresponding to the number of
tokens that should be issued.
Firstly, the "IssuedToken" type corresponds to a single sequence of
bytes that represents a single issued token received from the Issuer.
The value of "m" is equal to the length of the "IssuanceMessage"
vector sent by the Client.
Note that a "IssuanceInput" contains equal-length arrays of
"Internal" and "IssuanceRequest" types corresponding to the number of
tokens that should be issued.
Firstly, the "IssuedToken" type corresponds to a single sequence of
bytes that represents a single issued token received from the server.
The value of "m" is equal to the length of the "IssuanceRequest"
vector sent by the client.
The "RedemptionMessage" struct consists of the data that is sent by
the client during the redemption phase of the protocol.
The "RedemptionResponse" struct corresponds to a boolean value that
indicates whether the "RedemptionMessage" sent by the client is
valid.  It can also contain any associated data.
The "RedemptionRequest" struct consists of the data that is sent by
the client during the redemption phase of the protocol.
The "RedemptionResponse" struct corresponds to a boolean value that
indicates whether the "RedemptionRequest" sent by the client is
valid.  It can also contain any associated data.
"msg": An "IssuanceMessage" struct.
"pkS": A server "PublicKey".
"skS": A server "PrivateKey".
"req": An "IssuanceRequest" struct.
"skS": An server "PrivateKey".
The adversary runs the Issuer setup and generates a keypair "(pkI,
skI)".
The adversary runs the server setup and generates a keypair "(pkS,
skS)".
The adversary specifies a number "Q" of issuance phases to
initiate with the Issuer, where each phase "i in range(Q)"
consists of "m_i" Issuer evaluation.  Let "m = sum(m_i)" where "i
in range(Q)".
The adversary initiates "m_adv" redemption sessions with the
Issuer and the Issuer verifies that the sessions are successful
(return true), and that each request includes a unique token.  The
adversary succeeds in "m_succ =< m_adv" redemption sessions.
The adversary specifies a number "Q" of issuance phases to
initiate with the server, where each phase "i in range(Q)"
consists of "m_i" server evaluation.  Let "m = sum(m_i)" where "i
in range(Q)".
The adversary initiates "m_adv" redemption sessions with the
server and the server verifies that the sessions are successful
(return true), and that each request includes a unique token.  The
adversary succeeds in "m_succ =< m_adv" redemption sessions.
All issuing servers should implement a robust, global storage-query
mechanism for checking that tokens sent by clients have not been
spent before.  Such tokens only need to be checked for each issuer
individually.  This prevents clients from "replaying" previous
requests, and is necessary for achieving the unforgeability
requirement.
All issuing servers should implement a robust, global storage-query
mechanism for checking that tokens sent by clients have not been
spent before.  Such tokens only need to be checked for each server
individually.  This prevents clients from "replaying" previous
requests, and is necessary for achieving the unforgeability
requirement.
Some use-cases of the Privacy Pass protocol benefit from associating
a limited amount of metadata with tokens that can be read by the
Issuer when a token is redeemed.  Adding metadata to tokens can be
used as a vector to segment the anonymity of the Client in the
protocol.  Therefore, it is important that any metadata that is added
is heavily limited.
Some use-cases of the Privacy Pass protocol benefit from associating
a limited amount of metadata with tokens that can be read by the
server when a token is redeemed.  Adding metadata to tokens can be
used as a vector to segment the anonymity of the client in the
protocol.  Therefore, it is important that any metadata that is added
is heavily limited.
Note that the instantiation in voprf-protocol provides randomized
redemption tokens with no additional metadata for an Issuer with a
single key.
Note that the instantiation in voprf-protocol provides randomized
redemption tokens with no additional metadata for an server with a
single key.
Note that we must run the verifiable version of the protocol in I-
D.irtf-cfrg-voprf.  Therefore the "Issuer" takes the role of the
"Server" running in "modeVerifiable".  In other words, the "Issuer"
runs "(ctxtI, pkI) = SetupVerifiableServer(suite)"; where "suite" is
one of the ciphersuites in voprf-ciph-recs, "ctxt" contains the
internal VOPRF Server functionality and secret key "skI", and "pkI"
is the Issuer public key.  Likewise, run "ctxtC =
SetupVerifiableClient(suite)" to generate the Client context.
Note that we must run the verifiable version of the protocol in I-
D.irtf-cfrg-voprf.  Therefore the "server" takes the role of the
"Server" running in "modeVerifiable".  In other words, the "server"
runs "(ctxtI, pkS) = SetupVerifiableServer(suite)"; where "suite" is
one of the ciphersuites in voprf-ciph-recs, "ctxt" contains the
internal VOPRF server functionality and secret key "skS", and "pkS"
is the server public key.  Likewise, run "ctxtC =
SetupVerifiableClient(suite)" to generate the Client context.
For this functionality, note that we supply multiple tokens in "msg"
to "Evaluate".  This allows batching a single proof object for
multiple evaluations.  While the construction in I-D.irtf-cfrg-voprf
only permits a single input, we follow the advice for providing
vectors of inputs.
For this functionality, note that we supply multiple tokens in "req"
to "Evaluate".  This allows batching a single proof object for
multiple evaluations.  While the construction in I-D.irtf-cfrg-voprf
only permits a single input, we follow the advice for providing
vectors of inputs.
A Client SHOULD fetch the Server configuration and current public key
commitments prior to performing issuance and redemption.  This
configuration is accessible via a "CONFIG_ENDPOINT", either provided
by the Server or by a global registry that provides consistency and
anonymization guarantees.
A client SHOULD fetch a server's current public key information prior
to performing issuance and redemption.  This configuration is
accessible via a "CONFIG_ENDPOINT", either provided by the server or
by a global registry that provides consistency and anonymization
guarantees.
When a Client wants to request tokens from a server, it should
first fetch a key commitment from the issuer via the process
described in key-commitment and keep the result as "commitment".
When a client wants to request tokens from a server, it should
first fetch a key commitment from the server via the process
described in key-commitment and keep the result as "commitment".
How clients should evaluate Issuer trust relationships.
How clients should evaluate server trust relationships.
Server: An entity that issues anonymous tokens to clients.  In
symmetric verification cases, the Server must also verify tokens.
Also referred to as the Issuer.
Server: An entity that issues anonymous tokens to clients.  In
symmetric verification cases, the server must also verify tokens.
Also referred to as the server.
Generally, Servers in the Privacy Pass ecosystem are entities whose
primary function is to undertake the role of the "Issuer" in draft-
davidson-pp-protocol.  To facilitate this, the Issuer MUST hold a
Privacy Pass protocol keypair 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 Issuer MAY
also require additional state for ensuring this.  We provide a wider
discussion in key-mgmt.
Note that, in the core protocol instantiation from draft-davidson-pp-
protocol, the redemption phase is a symmetric protocol.  This means
that the Issuer is the same Server that ultimately processes token
redemptions from Clients.  However, plausible extensions to the
protocol specification may allow public verification of tokens by
entities which do not hold the secret Privacy Pass keying material.
We highlight possible Client and Server configurations in running-
modes.
Generally, servers in the Privacy Pass ecosystem are entities whose
primary function is to undertake the role of the "server" in draft-
davidson-pp-protocol.  To facilitate this, the server MUST hold a
Privacy Pass protocol keypair at any given time.  The server public
key MUST be made available to all clients in such a way that key
rotations and other updates are publicly visible.  The server MAY
also require additional state for ensuring this.  We provide a wider
discussion in key-mgmt.
Note that, in the core protocol instantiation from draft-davidson-pp-
protocol, the redemption phase is a symmetric protocol.  This means
that the server is the same server that ultimately processes token
redemptions from clients.  However, plausible extensions to the
protocol specification may allow public verification of tokens by
entities which do not hold the secret Privacy Pass keying material.
We highlight possible client and server configurations in running-
modes.
Clients MAY choose not to accept tokens from Servers that they do not
trust.  See client-issuer for a wider discussion.
Clients MAY choose not to accept tokens from servers that they do not
trust.  See client-server for a wider discussion.
Issuer's must provide their public keys to clients along with details
about the cryptographic ciphersuite that they are using.  In privacy,
we address the importance of providing Clients with sources of truth
for learning the Server's key configuration.
Server's must provide their public keys to clients along with details
about the cryptographic ciphersuite that they are using.  In privacy,
we address the importance of providing clients with sources of truth
for learning the server's key configuration.
It is RECOMMENDED that each key registry is an append-only data
structure, such as a Merkle Tree.  The key registry should be
operated independently of any Issuer that publishes key material to
the registry.  This ensures that any Client can make better
judgements on whether to trust the registry and, transitively, each
Server.
It is RECOMMENDED that each key registry is an append-only data
structure, such as a Merkle Tree.  The key registry should be
operated independently of any server that publishes key material to
the registry.  This ensures that any client can make better
judgements on whether to trust the registry and, transitively, each
server.
The simplest way of considering the Privacy Pass protocol is in a
setting where the same server plays the role of issuer and verifier,
we call this "Single-Issuer Single-Verifier" (SISV).
When S wants to issue tokens to C, they invoke the issuance protocol
where C generates their own inputs, and S uses their secret key skS.
In this setting, C can only perform token redemption with S.  When a
token redemption is required, C and S invoke the redemption phase of
the protocol, where C uses an issued token from a previous exchange,
and S uses skS to validate the redemption.
In this setting, each Client C obtains issued tokens from a Server S
via the issuance phase of the protocol.  The difference is that C can
prove that they hold a valid authorization with any verifier V.  We
still only consider S to hold their own secret key.  We name this
mode "Single-Issuer Delegated-Verifier" (SIDV).
When C interacts with V, V can ask C to provide proof of
authorization to the separate issuer S.  The first stage of the
redemption phase of the protocol is invoked between C and V, which
sees C send an unused redemption token to V.  This message is then
used in a redemption exchange between V and S, where V plays the role
of the Client.  Then S sends the result of the redemption
verification to V, and V uses this result to determine whether C has
a valid token.
The simplest way of considering the Privacy Pass protocol is in a
setting where the same server plays the role of server and verifier,
we call this "Single-Verifier" (SV).
Let S be the server, and C be the client.  When S wants to issue
tokens to C, they invoke the issuance protocol where C generates
their own inputs, and S uses their secret key skS.  In this setting,
C can only perform token redemption with S.  When a token redemption
is required, C and S invoke the redemption phase of the protocol,
where C uses an issued token from a previous exchange, and S uses skS
to validate the redemption.
In this setting, each client C obtains issued tokens from a derver S
via the issuance phase of the protocol.  The difference is that C can
prove that they hold a valid authorization with any verifier V.  We
still only consider S to hold their own secret key.  We name this
mode "Delegated-Verifier" (DV).
When C interacts with V, V can ask C to provide proof of
authorization to the separate server S.  The first stage of the
redemption phase of the protocol is invoked between C and V, which
sees C send an unused redemption token to V.  This message is then
used in a redemption exchange between V and S, where V plays the role
of the Client.  Then S sends the result of the redemption
verification to V, and V uses this result to determine whether C has
a valid token.
This setting is inspired by recently proposed APIs such as
TrustTokenAPI.  It is similar to the SIDV configuration, except that
the verifiers V no longer interact with the issuer S.  Only C
interacts with S, and this is done asynchronously to the
authorization request from V.  Hence "Asynchronous-Verifier" (SIAV).
This setting is inspired by recently proposed APIs such as
TrustTokenAPI.  It is similar to the DV configuration, except that
the verifiers V no longer interact with the server S.  Only C
interacts with S, and this is done asynchronously to the
authorization request from V.  Hence "Asynchronous-Verifier" (AV).
The "signature" field carries a signature evaluated over the contents
of "result" using a long-term signing key for the issuer S, of which
the corresponding public key is well-known to C and V.  This would
need to be published alongside other public key data for S.  Then C
can prove that they hold a valid authorization from S to V by sending
the SRR to V.  The SRR can be verified by V by verifying the
signature, using the well-known public key for S.
The "signature" field carries a signature evaluated over the contents
of "result" using a long-term signing key for the server S, of which
the corresponding public key is well-known to C and V.  This would
need to be published alongside other public key data for S.  Then C
can prove that they hold a valid authorization from S to V by sending
the SRR to V.  The SRR can be verified by V by verifying the
signature, using the well-known public key for S.
Such records can be cached to display again in the future.  The
issuer can also add an expiry date to the record to determine when
the client must refresh the record.
We consider the case where Client redemptions can be verified
publicly using the Issuer public key.  This allows for defining
extensions of Privacy Pass that use public-key cryptography to allow
public verification.
In this case, the Client C obtains a redemption token from S.  The
redemption token is publicly verifiable in the sense that any entity
that knows the public key for S can verify the token.  This running
mode is known as "Single-Issuer Public-Verifier" (SIPV).
Each of the configurations above can be generalized to settings where
a bounded number of issuers are allowed, and verifiers can invoke
authorization verification for any of the available issuers.
Subsequently, this leads to three new configurations known as BISV,
BIFV, BIAV and BIPV.
As we will discuss later in privacy, configuring a large number of
issuers can lead to privacy concerns for the clients in the
ecosystem.  Therefore, we are careful to ensure that the number of
issuers is kept strictly bounded.  The actual issuers can be replaced
with different issuers as long as the total never exceeds this bound.
Moreover, issuer replacements also have an effect on client anonymity
that is similar to when a key rotation occurs.  Issuer so replacement
should only be permitted at similar intervals.
See privacy for more details about safe choices of this bound.
It is important, based on the architecture above, that any Client can
determine whether it would like to interact with a given Issuer in
the ecosystem.  Note that this decision must be taken before a Client
issues a valid redemption to the Server, since redemptions reveal the
anonymity set that the Client belongs to.
It should be noted that the Client trust decision can be made apriori
by specifying an allow-list of all Issuers that it accepts tokens
from.  This means that these checks do not have to be performed
online.
Such records can be cached to display again in the future.  The
server can also add an expiry date to the record to determine when
the client must refresh the record.
We consider the case where client redemptions can be verified
publicly using the server public key.  This allows for defining
extensions of Privacy Pass that use public-key cryptography to allow
public verification.
In this case, the client C obtains a redemption token from S.  The
redemption token is publicly verifiable in the sense that any entity
that knows the public key for S can verify the token.  This running
mode is known as "Public-Verifier" (PV).
Each of the configurations above can be generalized to settings where
a bounded number of servers are allowed, and verifiers can invoke
authorization verification for any of the available servers.
As we will discuss later in privacy, configuring a large number of
servers can lead to privacy concerns for the clients in the
ecosystem.  Therefore, we are careful to ensure that the number of
servers is kept strictly bounded.  The actual servers can be replaced
with different servers as long as the total never exceeds this bound.
Moreover, server replacements also have an effect on client anonymity
that is similar to when a key rotation occurs. server so replacement
should only be permitted at similar intervals.
See privacy for more details about maintaining privacy with multiple
servers.
It is important, based on the architecture above, that any client can
determine whether it would like to interact with a given server in
the ecosystem.  Note that this decision must be taken before a client
issues a valid redemption to the server, since redemptions reveal the
anonymity set that the client belongs to.
It should be noted that the client trust decision can be made apriori
by specifying an allow-list of all servers that it accepts tokens
from.  This means that these checks do not have to be performed
online.
In the following, we consider the possible ways that Servers and
Issuers can leverage their position to try and reduce the anonymity
sets that Clients belong to (or, user segregation).  For each case,
we provide mitigations that the Privacy Pass ecosystem must implement
to prevent these actions.
Similarly to the Issuer rotation dynamic that is raised above, if
there are a large number of Issuers then segregation can occur.  In
the BIFV, BIAV and BIPV running modes (running-modes), a verifier OV
can trigger redemptions for any of the available Issuers.  Each
redemption token that a client holds essentially corresponds to a bit
of information about the client that OV can 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 OV 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.
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, as highlighted in
parametrization, having a very large user base (> 5 million users),
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 server
configuration during the protocol.
The bounds on the numbers of Issuers that we proposed above are very
restrictive.  This is due to the fact that we considered a situation
where a Client could be issued (and forced to redeem) tokens for any
issuing key.
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 they possess tokens for is still revealing.  Understanding
this trade-off is important in deciding the effective anonymity of
each Client in the system.
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 Issuer's in the
ecosystem, and within the guidelines stated in key-mgmt.  Any Client
should follow the recommendations in client-issuer for determining
whether an Issuer and its key material should be trusted.
In the following, we consider the possible ways that servers and
servers can leverage their position to try and reduce the anonymity
sets that clients belong to (or, user segregation).  For each case,
we provide mitigations that the Privacy Pass ecosystem must implement
to prevent these actions.
Similarly to the server rotation dynamic that is raised above, if
there are a large number of servers then segregation can occur.  In
the FV, AV and PV running modes (running-modes), a verifier OV can
trigger redemptions for any of the available servers.  Each
redemption token that a client holds essentially corresponds to a bit
of information about the client that OV can learn.  Therefore, there
is an exponential loss in anonymity relative to the number of servers
that there are.
For example, if there are 32 servers, then OV learns 32 bits of
information about the client.  If the distribution of server 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 servers at any one time.
In cases where clients can hold tokens for all servers at any given
time, a strict bound SHOULD be applied to the active number of
servers in the ecosystem.  We propose that allowing no more than 4
servers at any one time is highly preferable (leading to a maximum of
64 possible user segregations).  However, as highlighted in
parametrization, having a very large user base (> 5 million users),
could potentially allow for larger values. server 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 servers.
In addition, we RECOMMEND that trusted registries indicate at all
times which servers are deemed to be active.  If a client is asked to
invoke any Privacy Pass exchange for an server that is not declared
active, then the client SHOULD refuse to retrieve the server
configuration during the protocol.
The bounds on the numbers of servers that we proposed above are very
restrictive.  This is due to the fact that we considered a situation
where a client could be issued (and forced to redeem) tokens for any
issuing key.
An alternative system is to ensure a robust strategy for ensuring
that clients only possess redemption tokens for a similarly small
number of servers at any one time.  This prevents a malicious
verifier from being able to invoke redemptions for many servers since
the client would only be holding redemption tokens for a small set of
servers.  When a client is issued tokens from a new server and
already has tokens from the maximum number of servers, 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 servers, 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 servers were
permitted across the whole system.  For example, these 4 servers
could be different for each client.  Therefore, the selection of
servers they possess tokens for is still revealing.  Understanding
this trade-off is important in deciding the effective anonymity of
each client in the system.
If there are multiple key registries, or if a key registry colludes
with an server, then it is possible to provide a split-view of an
server'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 server's in the
ecosystem, and within the guidelines stated in key-mgmt.  Any client
should follow the recommendations in client-server for determining
whether an server and its key material should be trusted.
Note that any arbitrary bits of information can be used to further
segment the size of the user's anonymity set.  Any Issuer that wanted
to track a single user could add a single metadata bit to user
tokens.  For the tracked user it would set the bit to "1", and "0"
otherwise.  Adding additional bits provides an exponential increase
in tracking granularity similarly to introducing more Issuers (though
with more potential targeting).
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 Issuer's may learn about Clients otherwise.  We
discuss this more in parametrization.
Note that any arbitrary bits of information can be used to further
segment the size of the user's anonymity set.  Any server that wanted
to track a single user could add a single metadata bit to user
tokens.  For the tracked user it would set the bit to "1", and "0"
otherwise.  Adding additional bits provides an exponential increase
in tracking granularity similarly to introducing more servers (though
with more potential targeting).
For this reason, the amount of metadata used by an server in creating
redemption tokens must be taken into account - together with the bits
of information that server's may learn about clients otherwise.  We
discuss this more in parametrization.
Privacy losses may be encountered if too many redemptions are allowed
in a short burst.  For instance, in the Internet setting, this may
allow delegated or asynchronous verifiers to learn more information
from the metadata that the Client may hold (such as first-party
cookies for other domains).  Mitigations for this issue are similar
to those proposed in issuers for tackling the problem of having large
number of issuers.
In SIAV, cached SRRs and their associated issuer public keys have a
similar tracking potential to first party cookies in the browser
setting.  These considerations will be covered in a separate
document, detailing Privacy Pass protocol integration into the wider
web architecture draft-svaldez-pp-http-api.
Privacy losses may be encountered if too many redemptions are allowed
in a short burst.  For instance, in the Internet setting, this may
allow delegated or asynchronous verifiers to learn more information
from the metadata that the client may hold (such as first-party
cookies for other domains).  Mitigations for this issue are similar
to those proposed in servers for tackling the problem of having large
number of servers.
In AV, cached SRRs and their associated server public keys have a
similar tracking potential to first party cookies in the browser
setting.  These considerations will be covered in a separate
document, detailing Privacy Pass protocol integration into the wider
web architecture draft-svaldez-pp-http-api.
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 issuers for more details.
All issuing server should implement a robust storage-query mechanism
for checking that tokens sent by Clients have not been spent before.
Such tokens only need to be checked for each issuer individually.
But all Issuers must perform global double-spend checks to avoid
Clients from exploiting the possibility of spending tokens more than
once against distributed token checking systems.  For the same
reason, the global data storage must have quick update times.  While
an update is occurring it may be possible for a malicious Client to
spend a token more than once.
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.
All issuing server should implement a robust storage-query mechanism
for checking that tokens sent by clients have not been spent before.
Such tokens only need to be checked for each server individually.
But all servers must perform global double-spend checks to avoid
clients from exploiting the possibility of spending tokens more than
once against distributed token checking systems.  For the same
reason, the global data storage must have quick update times.  While
an update is occurring it may be possible for a malicious client to
spend a token more than once.
When a Client holds tokens for an issuer, it is possible for any
verifier to invoke 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 for a given issuer.  To prevent
this from happening, methods should be put into place to prevent many
tokens from being redeemed at once.
In SIAV, the Client instead caches the SRR that it received in the
asynchronous redemption exchange with the issuer.  If the same
verifier attempts another redemption request, then the Client simply
returns the cached SRR.  The SRRs can be revoked by the issuer, if
need be, by providing an expiry date or by signaling that records
from a particular window need to be refreshed.
When a client holds tokens for an server, it is possible for any
verifier to invoke that client to redeem tokens for that server.
This can lead to an attack where a malicious verifier can force a
client to spend all of their tokens for a given server.  To prevent
this from happening, methods should be put into place to prevent many
tokens from being redeemed at once.
In AV, the client instead caches the SRR that it received in the
asynchronous redemption exchange with the server.  If the same
verifier attempts another redemption request, then the client simply
returns the cached SRR.  The SRRs can be revoked by the server, if
need be, by providing an expiry date or by signaling that records
from a particular window need to be refreshed.
Firstly, let U be the total number of users, I be the total number of
issuers.  We let M be the total number of metadata bits that are
allowed to be added by any given issuer.  Assuming that each user
accept tokens from a uniform sampling of all the possible issuers, as
a worst-case analysis, this segregates users into a total of 2^I
buckets.  As such, we see an exponential reduction in the size of the
anonymity set for any given user.  This allows us to specify the
privacy constraints of the protocol below, relative to the setting of
A.
Firstly, let U be the total number of users, I be the total number of
servers.  We let M be the total number of metadata bits that are
allowed to be added by any given server.  Assuming that each user
accept tokens from a uniform sampling of all the possible servers, as
a worst-case analysis, this segregates users into a total of 2^I
buckets.  As such, we see an exponential reduction in the size of the
anonymity set for any given user.  This allows us to specify the
privacy constraints of the protocol below, relative to the setting of
A.
The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A.
This is derived from the fact that permitting I issuers lead to 2^I
segregations of the total user-base U.  Moreover, if we permit M = 1,
then this effectively halves the anonymity set for each issuer, and
thus we incur a factor of 2I in the exponent.  By reducing I, we
limit the possibility of performing the attacks mentioned in privacy.
The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A.
This is derived from the fact that permitting I servers lead to 2^I
segregations of the total user-base U.  Moreover, if we permit M = 1,
then this effectively halves the anonymity set for each server, and
thus we incur a factor of 2I in the exponent.  By reducing I, we
limit the possibility of performing the attacks mentioned in privacy.
If the value of U is much bigger (e.g. 5 million) then this would
permit I = (log_2(5000000/5000)-1)/2 ~= 4 issuers.
Using the recommendations in more-issuers, it is possible to tolerate
larger number of Issuers if Clients in the ecosystem ensure that they
only store tokens for a small number of them.  In particular, if
Clients limit their storage of redemption tokens to the bound implied
by I, then prevents a malicious verifier from triggering redemptions
for all Issuers in the ecosystem.
If the value of U is much bigger (e.g. 5 million) then this would
permit I = (log_2(5000000/5000)-1)/2 ~= 4 servers.
Using the recommendations in more-servers, it is possible to tolerate
larger number of servers if clients in the ecosystem ensure that they
only store tokens for a small number of them.  In particular, if
clients limit their storage of redemption tokens to the bound implied
by I, then prevents a malicious verifier from triggering redemptions
for all servers in the ecosystem.
Any extension to the Privacy Pass protocol must adhere to the
guidelines specified in key-mgmt for managing Issuer public key data.
Any extension to the Privacy Pass protocol must adhere to the
guidelines specified in key-mgmt for managing server public key data.