Draft: draft-ietf-privacypass-protocol

Commentary: The new aligned diagrams that match across the architecture , protocol , and auth - scheme documents should address by making it clear how the tokens are used . 
 The protocol descriptions in the protocol draft ( Sections 5 and 6 ) do n't include a heading for token redemption . It looks like the finalization step is where some of that happens , but it seems fairly crucial for the draft to explain that clients to remove blinding and then construct a token that can be then they send it to the origin . There is a similar problem in the architecture draft where the " redemption " protocol does n't show the challenge - response flow , or even a spontaneous flow . That is left for the section following , which covers issuance . 
 I think we can probably address this by including " end to end " examples in the architecture document . The auth - scheme and protocol documents try to focus on their respective protocols . That is , the auth scheme creates token challenges and then consumes tokens , whereas the issuance spec takes token challenges as input and produces tokens as output . thoughts ? 
 There are claims in about the value of truncating the issuer 's key identifier that I do n't think hold outside of having some sort of consistency . Let 's say that I - your hypothetical attacker - want to partition users into 257 groups . I give the first 255 groups a unique key for which the last byte of is distinct . For the last two users , I can generate two keys that map to the remaining byte value . For the private validation setting , I can issue clients with unique values for and tokens that match . When validating the token , that 's me ( the attacker ) again , so I can validate against both keys . The complexity of my operation has doubled , but it 's a linear search and maybe I can keep the numbers down to manage overall costs . In a public validation setting , I have to ensure that any entity that might validate the tokens also gets a matching value for , or that they are complicit in the attack and so are willing to do the extra work . Generally , this is only the client still , so this is probably achievable , though there is a risk of an independent audit catching this . Going from 8 bits to 9 bits of partition space doubles the work for any validator , and each additional bit doubles again . That might be OK , but the claims would appear to be somewhat more absolute than this result implies : Also , even this is n't a great outcome either . 256 is pretty large , and the partitioning allocation ( again , absent consistency ) is under attacker control . 
 Good point . The bound was written under the assumption that the attacker does no work to tag clients , but that bound goes up provided it 's willing and able to keep more keys around . I think we ought to just drop the explicit bound check here and rewrite things to suggest that tagging is " not feasible at scale " ( or whatever ) , which is something I 'm comfortable with saying . Absent consistency , that 's the best sort of guarantee I think we 'll get . Beyond this editorial change , we could truncate the key identifier even further to make this tradeoff involve more work for the attacker . Going from 8 bits down to n \in { 2,3,4 } bits seems pretty reasonable to me , giving us a window of 2^n keys . 
 2 ^ 4 seems reasonable to me . 2 ^ 2 is too tight for managing rotations and leaves very little room to monitor for clients using incorrect / stale keyids . ( A fairly standard 3 - key rotation cycle means 3/4 of all expired keyid 's would still appear valid to the issuer at any given time . ) 
 Discussing leaving it at 8 bits to keep aligned with OHTTP and ECH , and adding more text about this area and the requirements for consistency checks . 
 I do n't see alignment as a concern : the value is going to be conveyed in an 8 bit field , but you do n't have to use all the bits . Stronger emphasis on consistency is the direction I 'd be looking for , definitely . 
 I think we ought to keep the consistency discussion primarily in the architecture document . Any objections to that , and 
 There at least should be some strong pointers to that section in architecture , I think .
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defined in
BLINDRSA.  All security considerations described in the VOPRF and
blind RSA documents also apply in the Privacy Pass use-case.
Considerations related to broader privacy and security concerns in a
multi-Client and multi-Issuer setting are deferred to the
Architecture document ARCHITECTURE.  Moreover, deployment-specific
considerations regarding Client privacy when running the issuance
protocol, especially with respect to Client-specific identifiers such
as IP addresses that are revealed to the Attester and Issuer during
issuance, are also discussed in Section 4 of ARCHITECTURE.
Beyond these considerations, it is worth highlighting the fact that
Client TokenRequest messages contain truncated token key IDs.  This
is done to minimize the chance that an Issuer can use distinct keys
for targeting specific users.  Since the key ID is truncated to a
single byte, an Issuer can partition the set of Clients into at most
256 different anonymity sets.  On top of this key ID space, Clients
SHOULD apply some form of key consistency mechanism to help ensure
they are not being given unique keys; see CONSISTENCY for more
details.
This document outlines how to instantiate the Issuance protocol based
on the VOPRF defined in OPRF and blind RSA protocol defined in
BLINDRSA.  All security considerations described in the VOPRF and
blind RSA documents also apply in the Privacy Pass use-case.
Considerations related to broader privacy and security concerns in a
multi-Client and multi-Issuer setting are deferred to the
Architecture document ARCHITECTURE.  In particular, the privacy
considerations in Section 4 and Section 5 of ARCHITECTURE,
particularly those pertaining to Issuer Public Key rotation and
consistency (where consistency is as described in CONSISTENCY) and
Issuer selection, are relevant for implementations of the protocols
in this document.
Moreover, when a Client holds cross-origin tokens with empty
contexts, it is possible for any Origin in the cross-origin set to
deplete that Client set of tokens.  To prevent this from happening,
tokens can be scoped to single Origins (with non-empty origin_info)
such that they can only be redeemed for a single Origin.
Alternatively, if tokens are cross-Origin, Clients can use alternate
methods to prevent many tokens from being redeemed at once.  For
example, if the Origin requests an excess of tokens, the Client could
choose to not present any tokens for verification if a redemption had
already occurred in a given time window.
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 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 with a TokenChallenge (AUTHSCHEME, Section 2.1)
and, if possible, Clients present a valid Token (AUTHSCHEME,
Section 2.2) in response.  Alternatively, when configured to do so,
Clients may opportunistically present Token values to Origins without
a corresponding TokenChallenge.  This interaction is shown below.
The issuance protocol embodies the core of Privacy Pass.  It takes as
input a challenge from the redemption protocol and produces a token,
as shown in the figure below.
The Privacy Pass issuance protocol is a two-message protocol that
takes as input a TokenChallenge from the redemption protocol
(AUTHSCHEME, Section 2.1) and produces a Token (AUTHSCHEME,
Section 2.2), as shown in the figure below.
Clients obtain the Issuer public key directly from the Origin using
the process described in AUTHSCHEME.  Clients MAY apply some form of
key consistency check to determine if this public key is consistent
and correct for the specified Issuer.  See CONSISTENCY for example
mechanisms.  Depending on the deployment, the Attester might assist
the Client in applying these consistency checks across clients.
Depending on the use case, issuance may require some form of Client
anonymization service, similar to an IP-hiding proxy, so that Issuers
cannot learn information about Clients.  This can be provided by an
explicit participant in the issuance protocol, or it can be provided
via external means, such as through the use of an IP-hiding proxy
service like Tor. In general, Clients SHOULD minimize or remove
identifying information where possible when invoking the issuance
protocol.
Clients obtain the Issuer public key directly from the Origin using
the process described in AUTHSCHEME.  Clients can apply some form of
consistency check to determine if this public key is consistent and
correct for the specified Issuer.  See CONSISTENCY for example
mechanisms.  Depending on the deployment, the Attester might assist
the Client in applying these consistency checks across clients.  See
rotation-and-consistency for more information.  Failure to apply a
consistency check can allow Client-specific keys to impact the Client
anonymity set.  See rotation-and-consistency for more details.
Depending on the use case, issuance may require some form of Client
anonymization service, similar to an IP-hiding proxy, so that Issuers
cannot learn information about Clients.  This can be provided by an
explicit participant in the issuance protocol, or it can be provided
via external means, such as through the use of an IP-hiding proxy
service like Tor Dingledine2004.  In general, Clients SHOULD minimize
or remove identifying information where possible when invoking the
issuance protocol.
Issuers MUST be uniquely identifiable by all Clients with a
consistent identifier.  In a web context, this identifier might be
the Issuer host name.  As discussed in privacy, ecosystems that admit
a large number of Issuers can lead to privacy concerns for the
Clients in the ecosystem.  Therefore, in practice, the number of
Issuers should be bounded.  The actual Issuers can be replaced with
different Issuers as long as the total never exceeds these bounds.
Moreover, Issuer replacements also have an effect on client anonymity
that is similar to when a key rotation occurs.  See privacy for more
details about maintaining privacy with multiple Issuers.
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.  See key-
rotation-privacy for more considerations around Issuer key rotation.
The key material and protocol configuration that an Issuer uses to
produce tokens corresponds to two different pieces of information.
The public keys that are active for the Issuer.
Servers use a verifiable, tamper-free registry from which clients
discover keys.  Similar to related mechanisms and protocols such
as Certificate Transparency RFC6962, this may require external
auditors or additional client behavior to ensure the registry
state is consistent for all clients.
Clients use an anonymity-preserving tool such as Tor to discover
keys from multiple network vantage points.  This is done to ensure
consistent keys to seemingly different clients.
Clients embed Issuer keys into software.
As above, specific mechanisms for key management and discovery are
out of scope for this document.
Issuers are uniquely identifiable by all Clients with a consistent
identifier.  In a web context, this identifier might be the Issuer
host name.  Issuers maintain one or more configurations, including
issuance key pairs, for use in the issuance protocol.  Issuers can
rotate these configurations as needed to mitigate risk of compromise;
see rotation-and-consistency for more considerations around
configuration rotation.  The Issuer public key for each active
configuraton is made available to Origins and Clients for use in the
issuance and redemption protocols.
As discussed in privacy, ecosystems that admit a large number of
Issuers or Issuer configurations can lead to privacy concerns for the
Clients in the ecosystem.  Therefore, in practice, the number of
Issuers should be bounded and some mechanism should exist to ensure
that their active configurations are consistent for all Clients and
Origins interacting with the Issuer.  See privacy for more details
about maintaining privacy with multiple Issuers and multiple
configurations.
Private metadata is that which Clients cannot observe as part of the
token issuance flow.  Such instantiations may be built on the Private
Metadata Bit construction from Kreuter et al.  KLOR20 or the
attribute-based VOPRF from Huang et al.  HIJK21.
Private metadata is that which Clients cannot observe as part of the
token issuance flow.  Such instantiations can be built on the Private
Metadata Bit construction from Kreuter et al.  KLOR20 or the
attribute-based VOPRF from Huang et al.  HIJK21.
A Client uses Privacy 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.
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.
A Client uses Privacy Pass to separate attestation context and
redemption context.  This separation means that the attestation
context (or redemption context) for a Client does not uniquely
identify the redemption context (or attestation) context.  In other
words, for a given attestation context, there exists a sufficiently
large anonymity set of Clients that share the same redemption
context, and vice versa.
Maintaining these anonymity sets is a fundamental requirement for
Privacy Pass deployments.  In practice, there are a number of ways in
which these anonymity sets can be partitioned.  For example, as
discussed in deployment, failure to use a privacy-enhancing proxy
system such as Tor when interacting with Attesters, Isuers, or
Origins allows the anonymity set to be partitioned by the Client's IP
address.  Similarly, malicious Origins may attempt to partition the
anonymity set for a given redemption context by using Client-specific
Issuer public keys.
The following sections discuss issues that can influence Client
anonymity set.  For each issue, we discuss mitigations or safeguards
to protect against the underlying problem.
Issuer key rotation is important to hedge against long-term private
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.
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 Issuer security.  Therefore, it is still important that
key rotations occur on a regular cycle to reduce the harmfulness of
an Issuer key compromise.  If there are multiple Issuer keys in
rotation, Clients can apply some form of consistency mechanism
CONSISTENCY to ensure that they receive the same key as other
Clients.  Likewise, Origins can use one or more public keys for
redemption to support Issuer key rotation.
Issuer configuration updates, e.g., due to key rotation, are an
important part of hedging against long-term private 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.
Configuration changes can also be used to segment Client anonymity
sets.  In particular, when an Issuer updates their configuration and
the corresponding key pair, any Client that invokes the issuance
protocol with this configuration becomes be part of a set of Clients
which also ran the issuance protocol using the same configuration.
To mechanize this attack strategy, an Issuer could introduce a
configuration rotation policy that forces Clients into small
anonymity sets.
In general, key rotations represent a trade-off between Client
privacy and Issuer security.  Therefore, it is important that key
rotations occur on a regular cycle to reduce the harm of an Issuer
key compromise.  As a result, Clients SHOULD employ some form of
consistency mechanism to ensure that they receive the same
configuration information and are not being actively partitioned into
smaller anonymity sets.  See CONSISTENCY for possible consistency
mechanisms.
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 the others, the number of bits of information
the Origin can learn is bounded by the number of "redemption
partitions".
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".  Within each
partition, the Client would place an upper bound on the number of
allowed Issuers.  As long as each redemption partition maintains a
strong privacy boundary with the others, the number of bits of
information the Origin can learn is bounded by the number of
redemption partitions.
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.