Draft: draft-davidson-pp-protocol

Commentary: Add allowances in protocol doc for redemption metadata Provide privacy analysis of including  to architecture doc Update privacy parametrizations cc ( I do n't know everyone 's github usernames , so feel free to add others who will be interested in reviewing ) . 
 LGTM 
 The main protocol document assumes that VOPRF is the main instantiation of PrivacyPass . It also has support for ciphersuites that augment this particular instantiation . It 's not clear how we 'd " extend " this protocol to support other features , such as public verifiability or the k - bits of metadata . These seem to be separate " modes " or " configurations " of PrivacyPass . ( I do n't think it makes sense to try and cast the metadata bit variant as a different ciphersuite for the main instantiation . ) I propose we add some text describing different configurations . A configuration is an instantiation of the PrivacyPass API with certain properties . A configuration may ( should ? ) also be extensible where applicable , e.g. , in the ServerUpdate message or IssuanceRequest / Response messages . Interoperability across configurations would be unsupported , as they have would like have fundamentally different properties . Some initial configurations that come to mind are : PrivacyPass with no metadata bits ( VOPRF construction ) PrivacyPass with    ( Google 's design ) PrivacyPass with public verifiability ( blind signatures ? ) cc 
 Added some more information about supporting additional metadata in . As discussed elsewhere , I think the way to go here is for extensions to just specify new ciphersuites with associated privacy / security guarantees . 
 A number of applications expect the Servers to be able to add a small amount of metadata to the Privacy Pass protocol . We should add a discussion on how metadata should be to tokens , and then describe the subsequent impact that this would have on the client 's expected privacy budget . Generally speaking , adding a bit of metadata to  is likely to have a very similar impact to introducing an extra Issuer , and so this is something that will have to be covered in the general parametrization guidelines in the architecture document . Specific mechanisms for adding metadata to tokens are yet to be proposed , but may appear as alternative instantiations in the protocol document , or be specified separately as individual extensions . 
 LGTM . We ’ll need to work through the extensibility support for the metadata bit variant next .
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 protocol Clients.
Therefore, it is important that any metadata that is added is heavily
limited.
Any additional metadata that can be added to redemption tokens should
be described in the specific protocol instantiation.  Note that any
additional metadata will have to be justified in light of the privacy
concerns raised above.  For more details on the impacts associated
with segmenting user privacy, see draft-davidson-pp-architecture.
Any metadata added to tokens will be considered either "public" or
"private".  Public metadata corresponds to unmodifiable bits that a
client can read.  Private metadata corresponds to unmodifiable
private bits that should be obscured to the client.
Note that the instantiation in voprf-protocol provides randomized
redemption tokens with no additional metadata for an Issuer with a
single key.
This setting is inspired by recently proposed APIs such as TRUST.  It
is similar to the SIFV 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 trust attestation request from V.
Hence "Asynchronous-Verifier" (SIAV).
This setting is inspired by recently proposed APIs such as
TrustTokenAPI.  It is similar to the SIFV 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 trust
attestation request from V.  Hence "Asynchronous-Verifier" (SIAV).
As we noted in bi-mode, a strict bound should be applied to the
active number of issuers that are allowed at one time 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 (for example, up to 8 issuers).  Issuer
replacements should only occur with the same frequency as config
rotations as they can lead to similar losses in privacy if clients
still hold redemption tokens for previously active issuers.
As we noted in bi-mode, a strict bound should be applied to the
active number of issuers that are allowed at one time 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 privacy if clients still hold redemption tokens for
previously active issuers.
While redemption tokens themselves encode no information about the
client redeeming them, problems may occur if too many redemptions are
allowed in a short burst.  For instance, in the Internet setting,
this may allow non-terminating 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 draft-davidson-pp-protocol, it is permissible to add public and
private metadata bits to redemption tokens.  While the core protocol
instantiation that is described does not include additional metadata,
future instantiations may use this functionality to provide
redemption verifiers with additional information about the user.
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 from the means
listed above.  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 non-terminating 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.
Firstly, let U be the total number of users, I be the total number of
issuers.  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.
The maximum choice of I is based on the equation 1/2 * U/2^I = A.
This is because I issuers lead to 2^I segregations of the total user-
base U.  By reducing I we limit the possibility of performing the
attacks mentioned in segregation.
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.
Inferring the identity of a user in a 5000-strong anonymity set is
difficult.
After 2 weeks, all clients in a system will have rotated to the
new key.
In terms of additional metadata, the only concrete applications of
Privacy Pass that use additional metadata require just a single bit.
Therefore, we set the ceiling of permitted metadata to 1 bit for now,
this may be revisited in future revisions.
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
segregation.
Using the specification above, we can give some example
parameterizations.  For example, the current Privacy Pass browser
extension PPEXT has over 150,000 active users (from Chrome and
Firefox).  As a result, log_2(U/A) is approximately 5 and so the
maximum value of I should be 4.
If the value of U is much bigger (e.g. 5 million) then this would
permit I = log_2(5000000/5000)-1 = 8 issuers.
Using the specification above, we can give some example
parameterizations.  For example, the current Privacy Pass browser
extension PPEXT has nearly 300000 active users (from Chrome and
Firefox).  As a result, log_2(U/A) is approximately 6 and so the
maximum value of I should be 3.
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.
The Trust Token API TRUST has been devised as a generic API for
providing Privacy Pass functionality in the browser setting.  The API
is intended to be implemented directly into browsers so that server's
can directly trigger the Privacy Pass workflow.
The Trust Token API TrustTokenAPI has been devised as a generic API
for providing Privacy Pass functionality in the browser setting.  The
API is intended to be implemented directly into browsers so that
server's can directly trigger the Privacy Pass workflow.