]> Cloudflare Inc.

ot-ietf@thibault.uk

Security Privacy Pass This document specifies an instantiation of Privacy Pass Architecture that allows for a reverse flow from the Origin to the Client/Attester/Issuer. It describes a way for redeeming Origins to perform new issuances in the same request. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Privacy Pass Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document specifies an instantiation of Privacy Pass Architecture that allows for a reverse flow from the Origin to the Client/Attester/Issuer. In other words, it specifies a way for the Origin to act as a joint Attester/Issuer. A Client that has already been authorised by an Origin can maintain that authorization, without losing the unlinkability property provided by Privacy Pass. In addition, it allows an Origin to define its own issuance policy based on an initial bootstraping attestation method. For instance, an Origin that wants to grant 30 access for Clients that solved a CAPTCHA might consume a type 0x0002 public veriable token, and use it to issue 30 type 0x0001 private tokens.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. We reuse terminology from . The following terms are used throughout this document:

Flow:

Direction from PrivateToken issuance to its redemption. The entity starting the flow acts as an Issuer, while the end of the flow acts as an Origin. The Client is always included, as it finalises the TokenResponse, and coordinate interactions.

Initial Flow:

Issuer -> Attester -> Client -> Origin. This flow produces a PrivateToken that is used by the Origin to kickstart a Reverse Flow.

Reverse Flow:

Issuer <- Attester <- Client <- Origin. This flow allows Origin to issues PrivateToken. In the reverse flow, the Origin operates one or more Issuer, and the Client MAY provide these tokens either to the Initial Attester/Issuer, or use them against the Origin

Initial Attester/Issuer:

Attester/Issuer part of the Initial Flow

Origin Issuer:

Issuer operated by the Origin

Origin PrivateToken:

PrivateToken issued by the Origin

Reverse Origin:

An entity that consumes the Origin PrivateToken. It can be the Origin, or the Initial Attester/Issuer

Protocol overview Along with sending their PrivateToken for authentication (as specified in ), Client sends TokenRequest | | | | | |<== Attestation ==>| | | | | | | | | +--------- TokenRequest ------->| | | |<-------- TokenResponse -------+ | |<-- Request+Token+TokenRequest(Origin Issuer) --+ | | |<-- TokenRequest ---+ | | | +-- TokenResponse -->| | | | | |--- Response+TokenResponse(Origin Issuer) ----->| | | | | | | | ]]> The initial flow matches the one defined by . A Client gets challenged when accessing a resource on an Origin. The Client goes to the Attester to get issue a Token. Through configuration mechanism not defined in this document, the Client is aware the Origin acts as a Reverse Flow issuer. This is an extension of . The Client sends Request+Token+TokenRequest(Origin Issuer). The Origin runs the issuance protocol based, and returns Response+TokenResponse(Origin Issuer). TokenRequest(Origin Issuer) and TokenResponse(Origin Issuer) happen through a new HTTP Header PrivacyPass-Reverse. PrivacyPass-Reverse is a base64url () encoded BatchedTokenRequest as defined in .

• The use of arbitrary batched tokens as defined in is because this already provides encoding for request and response, error wrapping, and a concise format. One could use binary http or a new format

Client behaviour Along with sending PrivateToken from the Initial Issuer to the Origin, the Client sends a TokenRequest as defined in or , and wraps them as an arbitrary batched token request. The Client SHOULD consider Privacy Pass Reverse Flow like the initial flow. The Client is responsible to coordinate between the different entities. Specifically, if the Reverse Origin is the Initial Attester/Issuer, the Client SHOULD account for possible privacy leakage.

Origin/Issuer/Attester deployment In this model, the Origin, Attester, and Issuer are all operated by the same entity, as shown in . The Reverse Flow is the same as the Initial Flow, except for the request/response encapsulation. The Origin is the Reverse Origin.

Shared Deployment Model | | | | | | | +----------- TokenRequest ----------->| | |<---------- TokenResponse -----------+ | | | +------- Token+TokenRequest(Origin Issuer) -------->+ |<--------- TokenResponse(Origin Issuer) -----------| | | ]]>

Similar to the original Shared Deployment Model, the Attester, Issuer, and Origin share the attestation, issuance, and redemption contexts. Even if this context changes between the Initial and Reverse Flow, attestation mechanism that can uniquely identify a Client are not appropriate as they could lead to unlinkability violations.

Split Origin-Attester deployment In this model, the Attester and Issuer are operated by the same entity that is separate from the Origin. The Origin trusts the joint Attester and Issuer to perform attestation and issue Tokens. Origin Tokens can then be sent by Client on new requests, as long as the Reverse Origin trusts the Origin to perform attestation and issue Tokens.

Joint Attester and Issuer Deployment Model | | | | | |<== Attestation ==>| | | | | | | | | +--------- TokenRequest ------->| | | |<-------- TokenResponse -------+ | |<-- Request+Token+TokenRequest(Origin Issuer) --+ | | |<-- TokenRequest ---+ | | | +-- TokenResponse -->| | | | | |--- Response+TokenResponse(Origin Issuer) ----->| | | | | | | | ]]>

The Origin Issuer MUST not issue privately verifiable tokens, as this would lead to secret material being shared between the Origin and the Reverse Origin. A particular deployment model is when the Reverse Origin is the Attester/Issuer. This model is described in

Joint Attester and Issuer Deployment Model with reverse | | | | | |<== Attestation ==>| | | | | | | | | +--------- TokenRequest ------->| | | |<-------- TokenResponse -------+ | |<-- Request+Token+TokenRequest(Origin Issuer) --+ | | |<-- TokenRequest ---+ | | | +-- TokenResponse -->| | | | | |--- Response+TokenResponse(Origin Issuer) ----->| | | | | +------------ Token ----------->| | | | | | ]]>

This deployment SHOULD not allow the Reverse Origin to infer the request made to the Origin, as it would break unlinkability.

Privacy Considerations Privacy Pass states

• In general, limiting the amount of metadata permitted helps limit the extent to which metadata can uniquely identify individual Clients. Failure to bound the number of possible metadata values can therefore lead to a reduction in Client privacy. Most token types do not admit any metadata, so this bound is implicitly enforced.

In Privacy Pass with a reverse flow, Clients are provided with new PrivateTokens depending on their request. They can spend these tokens to continue making further requests. While the token are still unlinkable, the token_key_id associated to them represent metadata. It leaks some information about the Client. The following subsections discuss the issues that influence the anonymity set, and possible mitigations/safeguards to protect against this underlying problem.

Issuer face values When setting up a reverse flow deployment, an Origin MAY operate multiple Issuers, and assign them some metadata to them. The amount of possible metadata grows as 2^(origin_issuers). We RECOMMEND that:

1. Origin defines their anonimity sets, and deploy no more than log2(#anonimity_sets). This bounds the possible anonimity sets by design.
2. Client to only send 1 PrivateToken per request. This is inline with RFC9577 and RFC (Web Authentication) which only allows one challenge response to be provided as part of Authorization HTTP header.
3. Issuers metadata to be publicly disclosed via an origin endpoint, and externally monitored

Token for specific Clients In Privacy Pass with a reverse flow, an Origin MAY operate multiple Issuers, with arbitrary metadata associated to them. A malicious Origin MAY uses this opportunity to associate certain token values to a specific set of Clients. Let's consider the following deployment: the Origin operates two issuers A and B. The Client sends Token_A, and (TokenRequest_A, TokenRequest_B). Issuer B is associated to croissant aficionados. If a Client requests croissant, or sends Token_B, the origin provides TokenResponse_B. If not, it provides TokenResponse_A. Over time, this means the Origin is able to track croissants aficionados. To mitigate this, we RECOMMEND:

1. The initial PrivateToken to be provided by an Issuer not in control of the Origin. The joint Origin/Attester/Issuer model SHOULD NOT be used.
2. Clients to reset their state regularly with the initial Issuer.

Sending more than one token While that's not part of Privacy Pass with a reverse flow, some deployment might consider allowing Clients to send multiple PrivateToken, similar to how normal Privacy Pass deployment allow two distinct PrivateToken to be sent. In Privacy Pass with a reverse flow deployment, there are as many bits as Issuers; each token is one bit. We RECOMMEND to have a maximum of 6 Origin operated Issuers, bounding Client information to 2^6 = 64. Accounting for the initial Issuer, this means a total of log2(64)+1=7 issuers. Origin should have sufficient traffic to not single-out particular Client based on timings of requests.

Swap endpoint and its privacy implication With multiple Issuers, a Client MAY end up with a bunch of tokens, for various Issuers. Origins MAY propose a swap endpoint at which a Client can exchange one or more Origin tokens against one or more new Origin tokens. The Origin SHOULD ensure this endpoint receives enough traffic to not reduce the anonymity sets.

IANA Considerations This document has no IANA actions.

Normative References LIP Fastly Cloudflare This document specifies the Privacy Pass architecture and requirements for its constituent protocols used for authorization based on privacy-preserving authentication mechanisms. It describes the conceptual model of Privacy Pass and its protocols, its security and privacy goals, practical deployment models, and recommendations for each deployment model that helps ensure the desired security and privacy goals are fulfilled. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Phoenix R&D Cloudflare Cloudflare Inc. This document specifies a variant of the Privacy Pass issuance protocol that allows for batched issuance of tokens. This allows clients to request more than one token at a time and for issuers to issue more than one token at a time. This document specifies two variants of the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable using the Issuer Private Key and one that produces tokens that are publicly verifiable using the Issuer Public Key. Instances of "issuance protocol" and "issuance protocols" in the text of this document are used interchangeably to refer to the two variants of the Privacy Pass issuance protocol.

Acknowledgments The author would like to thank Tommy Pauly, Chris Wood, Raphael Robert, and Armando Faz Hernandez for helpful discussion on Privacy Pass architecture and its considerations.