Draft: draft-ietf-privacypass-http-api

Commentary: Initial work for fixing . 
 As discussed during IETF 110 , the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy . This is a bit of the calculus we do n't yet have . cc 
 Yeah , this likely needs to be embedded both into the Architecture draft for the generic concept of a context , and then an actual instantiation of redemption contexts in the HTTP API doc . 
 Yep should we split out the HTTP work into a separate issue ? 
 Thanks This looks good , I have mostly just a few nits to resolve .
The Privacy Pass protocol as described in draft-davidson-pp-protocol
can be integrated with a number of different settings, from server to
server communication to browsing the internet.
The Privacy Pass protocol as described in draft-ietf-privacypass-
protocol can be integrated with a number of different settings, from
server to server communication to browsing the internet.
We use the same definition of server and client that is used in
draft-davidson-pp-protocol and draft-davidson-pp-architecture.
We use the same definition of server and client that is used in
draft-ietf-privacypass-protocol and draft-ietf-privacypass-
architecture.
To avoid user segregation as a result of server configuration/
commitment rotation, the log operator SHOULD enforce limits on how
many active commitments exist and how quickly the commitments are
being rotated.  Clients SHOULD reject configurations/commitments that
violate their requirements for avoiding user segregation.  These
considerations are discussed as part of draft-davidson-pp-
architecture.
To avoid user segregation as a result of server configuration/
commitment rotation, the log operator SHOULD enforce limits on how
many active commitments exist and how quickly the commitments are
being rotated.  Clients SHOULD reject configurations/commitments that
violate their requirements for avoiding user segregation.  These
considerations are discussed as part of draft-ietf-privacypass-
architecture.
The client then verifies the signature for each key commitment and
stores the list of commitments to the current scope.  The client
SHOULD NOT cache the commitments beyond the current scope, as new
commitments should be fetched for each independent issuance and
redemption request.  The client SHOULD verify the
"inclusion_proofs" to confirm that the key commitment has been
submitted to a trusted registry.  Once the client receives the
"ciphersuite" for the server, it should implement all Privacy Pass
API functions (as detailed in draft-davidson-pp-protocol) using
this ciphersuite.
The client then verifies the signature for each key commitment and
stores the list of commitments to the current scope.  The client
SHOULD NOT cache the commitments beyond the current scope, as new
commitments should be fetched for each independent issuance and
redemption request.  The client SHOULD verify the
"inclusion_proofs" to confirm that the key commitment has been
submitted to a trusted registry.  Once the client receives the
"ciphersuite" for the server, it should implement all Privacy Pass
API functions (as detailed in draft-ietf-privacypass-protocol)
using this ciphersuite.
Inputs: - "server_id": The server ID to redeem a token against.  -
"ciphersuite": The ciphersuite for this token.  - "public_key": The
public key associated with this token.  - "redemption_token": A
Privacy Pass token.  - "info": Additional data to bind to this token
redemption.
In the HTTP ecosystem, redemption contexts should generally be keyed
by the same privacy boundary used for cookies and other local
storage.  Generally this is the top-level origin.  Any redemption
context should be built following the principles outlined in draft-
ietf-privacypass-architecture and later in privacy.
Inputs: - "context": The request context to use.  - "server_id": The
server ID to redeem a token against.  - "ciphersuite": The
ciphersuite for this token.  - "public_key": The public key
associated with this token.  - "redemption_token": A Privacy Pass
token.  - "info": Additional data to bind to this token redemption.
The client should check whether the "server_id" is present in the
"context".  If it isn't and the size of the "context" is beneath
the client's limit, it should be added.
Security considerations for Privacy Pass are discussed in draft-
davidson-pp-architecture.
Security considerations for Privacy Pass are discussed in draft-ietf-
privacypass-architecture.
General privacy considerations for Privacy Pass are discussed in
draft-ietf-privacypass-architecture.
In order to implement this API with redemption contexts, a client
needs to maintain strong privacy boundaries between different
redemption contexts to avoid privacy leakage from redemptions across
them.  Notably in the web/HTTP world, cross-site tracking and
fingerprinting will need to be considered and mitigated in order to
maintain these privacy boundaries.
Another option to allow a large number of servers 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 servers.  Within a redemption
context, the client limits the number of different servers 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".