Draft: draft-davidson-pp-protocol

Commentary: This is fine , though my suggestions in will conflict if landed first .
A common problem on the Internet is providing an effective mechanism
for servers to derive trust from clients they interact with.
Typically, this can be done by providing some sort of authorization
challenge to the client.  But this also negatively impacts the
experience of clients that regularly have to solve such challenges.
A common problem on the Internet is providing an effective mechanism
for servers to derive trust from clients that they interact with.
Typically, this can be done by providing some sort of authorization
challenge to the client.  But this also negatively impacts the
experience of clients that regularly have to solve such challenges.
The Privacy Pass protocol provides a set of cross-domain
authorization tokens that protect the client's anonymity in message
exchanges with a server.  This allows clients to communicate to a
server an attestation of a previously authenticated action, without
having to reauthenticate manually.  The tokens are retain anonymity
in the sense that the act of revealing them cannot be linked back to
the session where they were initially issued.
The Privacy Pass protocol provides a set of cross-domain
authorization tokens that protect the client's anonymity in message
exchanges with a server.  This allows clients to communicate an
attestation of a previously authenticated server action, without
having to reauthenticate manually.  The tokens retain anonymity in
the sense that the act of revealing them cannot be linked back to the
session where they were initially issued.
This document DOES NOT cover the architectural framework required for
running and maintaining the Privacy Pass protocol in the Internet
setting.  In addition, it DOES NOT cover the choices that are
necessary for ensuring that client privacy leaks do not occur.  Both
of these considerations are covered in a separate document draft-
davidson-pp-architecture.  A separate document draft-svaldez-pp-http-
api provides an instantiation of this protocol intended for the HTTP
setting.
This document DOES NOT cover the architectural framework required for
running and maintaining the Privacy Pass protocol in the Internet
setting.  In addition, it DOES NOT cover the choices that are
necessary for ensuring that client privacy leaks do not occur.  Both
of these considerations are covered in a separate document draft-
davidson-pp-architecture.  In addition, draft-svaldez-pp-http-api
provides an instantiation of this protocol intended for the HTTP
setting.
Issuer: A service that provides the server-side functionality
required by the protocol documented here.  May also be known as
the Server.
Key: The secret key used by the Server for authorizing client data
(typically denoted key).
Issuer: A service that provides the server-side functionality
required by the protocol.  May also be known as the Server.
Key: The secret key used by the Server for authorizing Client
data.
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 unique identifier "id" that is known to
the client.
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.  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 anonymous
authorization tokens from the Issuer.
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.
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 and then check against it in future sessions.  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.
It is possible for the API functions from pp-functions to return one
of the errors indicated in errors rather than their expected value.
In these cases, we assume that the entire protocol aborts.  If this
occurs during the server's operations for one of the documented
errors, then the server returns an error response indicating the
error type that occurred.
We provide an explicit instantiation of the Privacy Pass API, based
on the public API provided in I-D.irtf-cfrg-voprf.
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.
It is possible for the API functions from pp-functions to return one
of the errors indicated in errors rather than their expected value.
In these cases, we assume that the entire protocol aborts.
We provide an explicit instantiation of the Privacy Pass API in
voprf-api, based on the public API provided in I-D.irtf-cfrg-voprf.
The "Ciphersuite" enum provides identifiers for each of the supported
ciphersuites of the protocol.  Some initial values that are supported
by the core protocol are described in pp-ciphersuites.  Note that the
list of supported ciphersuites may be expanded by extensions to core
protocol description.
The "Ciphersuite" enum provides identifiers for each of the supported
ciphersuites of the protocol.  Some initial values that are supported
by the core protocol are described in pp-ciphersuites.  Note that the
list of supported ciphersuites may be expanded by extensions to the
core protocol description in separate documents.
We discuss the security requirements that are necessary to uphold
when instantiating the Privacy Pass protocol.  In particular, we
focus on the security requirements of "unlinkability", and
"unforgeability".  Informally, the notion of unlinkability is
required to preserve the anonymity of the client in the redemption
phase of the protocol.  The notion of unforgeability is to protect
against adversarial clients that look to subvert the security of the
protocol.
Since these are cryptographic security requirements we discuss them
with respect to a polynomial-time algorithm known as the adversary
that is looking to subvert the security guarantee.  More details on
both security requirements can be found in DGSTV18 and KLOR20.
Informally, the "unlinkability" requirement states that it is
impossible for an adversarial Issuer to link the Client's message in
a redemption session, to any previous issuance session that it has
encountered.
The adversary runs the Issuer setup and generates a Issue keypair
"(pkI, skI)".
We discuss the security requirements that are necessary to uphold
when instantiating the Privacy Pass protocol.  In particular, we
focus on the security requirements of "unlinkability", and
"unforgeability".  Informally, the notion of unlinkability is
required to preserve the anonymity of the Client in the redemption
phase of the protocol.  The notion of unforgeability is to protect
against an adversarial Client that may look to subvert the security
of the protocol.
Both requirements are modelled as typical cryptographic security
games, following the formats laid out in DGSTV18 and KLOR20.
The adversary runs the Issuer setup and generates a keypair "(pkI,
skI)".
The one-more unforgeability requirement states that it is hard for
any adversarial Client that has received "m" valid tokens from a
Issue to redeem "m+1" of them.  In essence, this requirement prevents
a malicious Client from being able to forge valid tokens based on the
Issue responses that it sees.
The one-more unforgeability requirement states that it is hard for
any adversarial Client that has received "m" valid tokens from the
issuance phase to redeem "m+1" of them.  In essence, this requirement
prevents a malicious Client from being able to forge valid tokens
based on the Issue responses that it sees.
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.
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.
Servers SHOULD impose a hard ceiling on the number of tokens that can
be issued in a single issuance phase to a Client.  If there is no
limit, malicious clients could abuse this and cause excessive
computation, leading to a Denial-of-Service attack.
We deliberately avoid the usage of smaller ciphersuites (associated
with P-256 and curve25519) due to the potential to reduce security
via static Diffie Hellman attacks.  See I-D.irtf-cfrg-voprf for more
details.
We deliberately avoid the usage of smaller ciphersuites (associated
with P-256 and curve25519) due to the potential to reduce security to
unfavourable levels via static Diffie Hellman attacks.  See I-D.irtf-
cfrg-voprf for more details.
For the explicit signatures of each of the functions, refer to pp-
api.
We instantiate each functions using the API functions in I-D.irtf-
cfrg-voprf.  Note that we use the framework mentioned in the document
to allow for batching multiple tokens into a single VOPRF evaluation.
For the explicit signatures of each of the functions, refer to pp-
api.
In each of the ciphersuites below, the maximum security provided
corresponds to the maximum difficulty of computing a discrete
logarithm in the group.  Note that the actual security level MAY be
lower, see the security considerations in I-D.irtf-cfrg-voprf for
examples.
In each of the ciphersuites below, the maximum security provided
corresponds to the maximum difficulty of computing a discrete
logarithm in the group.  Note that the actual security level MAY be
lower.  See the security considerations in I-D.irtf-cfrg-voprf for
examples.