Draft: draft-ietf-privacypass-architecture

Commentary: to some extent . cc 
 updated with citations . I 'll take , , and next . ( Trying to get these done before the upcoming deadline . ) 
 There are several dimensions to metadata , including : public vs private verifiable vs non - verifiable bounded or arbitrary - length It 's worth expanding on these dimensions . For example , the underlying cryptographic primitive may influence or limit one or more of these dimensions in a variety of ways . Also , whether  is public or private , or verifiable or not , is important for privacy reasons . ( If metadata ca n't be verified , is it a tracking vector ? Can private metadata track clients ? ) In general , expounding upon these issues would likely be quite valuable for the draft . 
 There 's currently no text around token expiration . Minimally , we could say that tokens expire when issuer ( and verifier )   . Do we also want to bake in mechanisms for expiration to be cryptographically bound to issued tokens ? For example , one might imagine using PMB - like constructions to encode an expiration " epoch " into the metadata bits . The single metadata bit variant would allow two epochs that way . what do you think ? 
 I 'm not sure what baking the expiry into the tokens gives that ca n't be managed by rotating the issuer / verifier keys ( or using public metadata ( which is effectively the key used to sign ) ) ? That way issuers that care about more fine grained token expiration use the key rotation for that and issuers that only care about coarse token expiration use it for other metadata , allowing the protocol to treat both in the same way ? 
 Yeah , I think the only two options are ( a ) rotate keys or ( b ) include the expiry information as public metadata ( and need not be tied to the key used to sign ) . I 'm not advocating for one or the other . Sure , that 's reasonable . We should probably have text on this point . ( That 's partly why I filed this issue . ) 
 We should also make sure to note that the validity window does narrow the anonymity set . 
 Token issuance and redemption flows from the same IP address , for example , would be linkable , but this is n't a break in the privacy pass protocol . We should discuss these orthogonal privacy considerations . 
 I think this is already addressed . if you agree , can you please close this ? 
 Yep , good point , closing . 
 We do n't have a good way to address this ( now ) , so we should minimally acknowledge the risks and consequences . 
 Dupe of . Closing . 
 LGTM ! I 'll take some of the other issues .
The Privacy Pass protocol provides an anonymity-preserving mechanism
for authorization of clients with servers.  The protocol is detailed
in draft-davidson-pp-protocol and is intended for use in the
application-layer.
The Privacy Pass protocol provides an anonymity-preserving mechanism
for authorization of clients with servers.  The protocol is detailed
in I-D.ietf-privacypass-protocol and is intended for use in the
application-layer.
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.
Generally, servers in the Privacy Pass ecosystem are entities whose
primary function is to undertake the role of the "server" in I-
D.ietf-privacypass-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 I-D.ietf-
privacypass-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 in the Privacy Pass ecosystem are entities whose primary
function is to undertake the role of the "Client" in draft-davidson-
pp-protocol.  Clients are assumed to only store data related to the
tokens that it has been issued by the server.  This storage is used
for constructing redemption requests.
Clients in the Privacy Pass ecosystem are entities whose primary
function is to undertake the role of the "Client" in I-D.ietf-
privacypass-protocol.  Clients are assumed to only store data related
to the tokens that it has been issued by the server.  This storage is
used for constructing redemption requests.
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.
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.
Certain instantiations of Privacy Pass may permit public or private
metadata to be cryptographically bound to a token.  As an example,
one trivial way to include public metadata is to assign a unique
issuer public key for each value of metadata, such that N keys yields
log2(N) bits of metadata.  The total amount of metadata bits included
in a token is the sum of public and private metadata bits.  See
parametrization for discussion about metadata limits.
Public metadata is that which clients can observe as part of the
token issuance flow.  Public metadata can either be transparent or
opaque.  For example, transparent public metadata is a value that the
client either generates itself, or the server provides during the
issuance flow and the client can check for correctness.  Opaque
public metadata is metadata the client can see but cannot check for
correctness.  As an example, the opaque public metadata might be a
"fraud detection signal", computed on behalf of the server, during
token issuance.  In normal circumstances, clients cannot determine if
this value is correct or otherwise a tracking vector.
Private metadata is that which clients cannot observe as part of the
token issuance flow.  In I-D.ietf-privacypass-protocol, it is
possible to include private metadata to redemption tokens.  The core
protocol instantiation that is described does not include additional
metadata.  However, future instantiations may use this functionality
to provide redemption verifiers with additional information about the
user.  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.
Note that any metadata 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.
Since this metadata may be useful for practical deployments of
Privacy Pass, servers must balance this against the reduction in
client privacy.  In general, servers should permit no more than 32
bits of metadata, as this can uniquely identify each possible user.
We discuss this more in parametrization.
In the Privacy Pass protocol draft-davidson-pp-protocol, redemption
tokens intentionally encode very little information beyond which key
was used to sign them.  The protocol intentionally uses components
that provide cryptographic guarantees of this fact.  However, even
with these guarantees, the way that the ecosystem is constructed can
be used to identify clients based on this limited information.
In the Privacy Pass protocol I-D.ietf-privacypass-protocol,
redemption tokens intentionally encode very little information beyond
which key was used to sign them.  The protocol intentionally uses
components that provide cryptographic guarantees of this fact.
However, even with these guarantees, the way that the ecosystem is
constructed can be used to identify clients based on this limited
information.
In draft-davidson-pp-protocol, it is permissible to add public and
private metadata bits to redemption tokens.  The core protocol
instantiation that is described does not include additional metadata.
However, 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 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.
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.
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 I-D.ietf-privacypass-http-api.
Firstly, a client behaving in this way would not be compliant with
the protocol, as laid out in draft-davidson-pp-protocol.
Firstly, a client behaving in this way would not be compliant with
the protocol, as laid out in I-D.ietf-privacypass-protocol.
Finally, the minimum security parameter size is related to the
cryptographic security offered by the protocol that is run.  This
parameter corresponds to the number of operations that any adversary
has in breaking one of the security guarantees in the Privacy Pass
protocol draft-davidson-pp-protocol.
Finally, the minimum security parameter size is related to the
cryptographic security offered by the protocol that is run.  This
parameter corresponds to the number of operations that any adversary
has in breaking one of the security guarantees in the Privacy Pass
protocol I-D.ietf-privacypass-protocol.
The Privacy Pass protocol and ecosystem are both intended to be
receptive to extensions that expand the current set of functionality.
As specified in draft-davidson-pp-protocol, all extensions to the
Privacy Pass protocol SHOULD be specified as separate documents that
modify the content of this document in some way.  We provide guidance
on the type of modifications that are possible in the following.
The Privacy Pass protocol and ecosystem are both intended to be
receptive to extensions that expand the current set of functionality.
As specified in I-D.ietf-privacypass-protocol, all extensions to the
Privacy Pass protocol SHOULD be specified as separate documents that
modify the content of this document in some way.  We provide guidance
on the type of modifications that are possible in the following.