idnits 2.17.1 draft-davidson-pp-architecture-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (13 July 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Davidson 3 Internet-Draft Cloudflare Portugal 4 Intended status: Informational 13 July 2020 5 Expires: 14 January 2021 7 Privacy Pass: Architectural Framework 8 draft-davidson-pp-architecture-01 10 Abstract 12 This document specifies the architectural framework for constructing 13 secure and anonymity-preserving instantiations of the Privacy Pass 14 protocol. It provides recommendations on how the protocol ecosystem 15 should be constructed to ensure the privacy of clients, and the 16 security of all participating entities. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 14 January 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Ecosystem participants . . . . . . . . . . . . . . . . . . . 4 54 3.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3.2.1. Client identifying information . . . . . . . . . . . 6 57 4. Key management framework . . . . . . . . . . . . . . . . . . 6 58 4.1. Public key registries . . . . . . . . . . . . . . . . . . 7 59 4.2. Key rotation . . . . . . . . . . . . . . . . . . . . . . 8 60 4.3. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Server running modes . . . . . . . . . . . . . . . . . . . . 9 62 5.1. Single-Verifier . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. Delegated-Verifier . . . . . . . . . . . . . . . . . . . 9 64 5.3. Asynchronous-Verifier . . . . . . . . . . . . . . . . . . 10 65 5.4. Public-Verifier . . . . . . . . . . . . . . . . . . . . . 10 66 5.5. Bounded number of servers . . . . . . . . . . . . . . . . 10 67 6. Client-Server trust relationship . . . . . . . . . . . . . . 11 68 7. Privacy considerations . . . . . . . . . . . . . . . . . . . 12 69 7.1. Server key rotation . . . . . . . . . . . . . . . . . . . 12 70 7.2. Large numbers of servers . . . . . . . . . . . . . . . . 13 71 7.2.1. Allowing larger number of servers . . . . . . . . . . 13 72 7.3. Partitioning of server key material . . . . . . . . . . . 14 73 7.4. Additional token metadata . . . . . . . . . . . . . . . . 14 74 7.5. Tracking and identity leakage . . . . . . . . . . . . . . 15 75 7.6. Client incentives for anonymity reduction . . . . . . . . 15 76 8. Security considerations . . . . . . . . . . . . . . . . . . . 15 77 8.1. Double-spend protection . . . . . . . . . . . . . . . . . 16 78 8.2. Token exhaustion . . . . . . . . . . . . . . . . . . . . 16 79 8.3. Avoiding server centralization . . . . . . . . . . . . . 16 80 9. Protocol parametrization . . . . . . . . . . . . . . . . . . 16 81 9.1. Justification . . . . . . . . . . . . . . . . . . . . . . 17 82 9.2. Example parameterization . . . . . . . . . . . . . . . . 18 83 9.3. Allowing more servers . . . . . . . . . . . . . . . . . . 19 84 10. Extension integration policy . . . . . . . . . . . . . . . . 19 85 11. Existing applications . . . . . . . . . . . . . . . . . . . . 19 86 11.1. Cloudflare challenge pages . . . . . . . . . . . . . . . 19 87 11.2. Trust Token API . . . . . . . . . . . . . . . . . . . . 20 88 11.3. Zero-knowledge Access Passes . . . . . . . . . . . . . . 20 89 11.4. Basic Attention Tokens . . . . . . . . . . . . . . . . . 20 90 11.5. Token Based Services . . . . . . . . . . . . . . . . . . 20 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 93 12.2. Informative References . . . . . . . . . . . . . . . . . 21 94 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 21 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 The Privacy Pass protocol provides an anonymity-preserving mechanism 100 for authorization of clients with servers. The protocol is detailed 101 in [draft-davidson-pp-protocol] and is intended for use in the 102 application-layer. 104 The way that the ecosystem around the protocol is set up can have 105 significant impacts on the stated privacy and security guarantees of 106 the protocol. For instance, the number of servers issuing Privacy 107 Pass tokens, along with the number of registered clients, determines 108 the anonymity set of each individual client. Moreover, this can be 109 influenced by other factors, such as: the key rotation policy used by 110 each server; and, the number of supported ciphersuites. There are 111 also client behavior patterns that can reduce the effective security 112 of the server. 114 In this document, we will provide a structural framework for building 115 the ecosystem around the Privacy Pass protocol. The core of the 116 document also includes policies for the following considerations. 118 * How server key material should be managed and accessed. 120 * Compatible server issuance and redemption running modes and 121 associated expectations. 123 * How clients should evaluate server trust relationships. 125 * Security and privacy properties of the protocol. 127 * A concrete assessment and parametrization of the privacy budget 128 associated with different settings of the above policies. 130 * The incorporation of potential extensions into the wider 131 ecosystem. 133 Finally, we will discuss existing applications that make use of the 134 Privacy Pass protocol, and highlight how these may fit with the 135 proposed framework. 137 2. Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 The following terms are used throughout this document. 145 * Server: An entity that issues anonymous tokens to clients. In 146 symmetric verification cases, the server must also verify tokens. 147 Also referred to as the server. 149 * Client: An entity that seeks authorization from a server. 151 We assume that all protocol messages are encoded into raw byte format 152 before being sent. We use the TLS presentation language [RFC8446] to 153 describe the structure of the data that is communicated and stored. 155 3. Ecosystem participants 157 The Privacy Pass ecosystem refers to the global framework in which 158 multiple instances of the Privacy Pass protocol operate. This refers 159 to all servers that support the protocol, or any extension of it, 160 along with all of the clients that may interact with these servers. 162 The ecosystem itself, and the way it is constructed, is critical for 163 evaluating the privacy of each individual client. We assume that a 164 client's privacy refers to fraction of users that it represents in 165 the anonymity set that it belongs to. We discuss this more in 166 Section 7. 168 +-----------------------------------------------------+ 169 | | 170 | Ecosystem | 171 | | 172 | | 173 | | 174 | +-----+ | 175 | | | +-----+ | 176 | | C1 | <--------------------> | | | 177 | | | | S1 | | 178 | +-----+ +-------------> | | | 179 | | +-----+ | 180 | | | 181 | +-----+ | | 182 | | | <------+ | 183 | | C2 | | 184 | | | <------+ +-----+ | 185 | +-----+ +-------------> | | | 186 | | S2 | | 187 | +-------------> | | | 188 | +-----+ | +-----+ | 189 | | | | | 190 | | C3 | <------+ | 191 | | | | 192 | +-----+ | 193 | | 194 +-----------------------------------------------------+ 196 In the above diagram, the arrows indicate the open channels between a 197 client and a server. An open channel indicates that a client accepts 198 Privacy Pass tokens from this server. 200 If no channel exists, this means that the client chooses not to 201 accept tokens from (or redeem tokens with) that particular server. 202 We discuss the roles of servers and clients further in Section 3.1 203 and Section 3.2, respectively. 205 3.1. Servers 207 Generally, servers in the Privacy Pass ecosystem are entities whose 208 primary function is to undertake the role of the "server" in 209 [draft-davidson-pp-protocol]. To facilitate this, the server MUST 210 hold a Privacy Pass protocol keypair at any given time. The server 211 public key MUST be made available to all clients in such a way that 212 key rotations and other updates are publicly visible. The server MAY 213 also require additional state for ensuring this. We provide a wider 214 discussion in Section 4. 216 Note that, in the core protocol instantiation from 217 [draft-davidson-pp-protocol], the redemption phase is a symmetric 218 protocol. This means that the server is the same server that 219 ultimately processes token redemptions from clients. However, 220 plausible extensions to the protocol specification may allow public 221 verification of tokens by entities which do not hold the secret 222 Privacy Pass keying material. We highlight possible client and 223 server configurations in Section 5. 225 The server must be uniquely identifiable by all clients with a 226 consistent identifier. 228 3.2. Clients 230 Clients in the Privacy Pass ecosystem are entities whose primary 231 function is to undertake the role of the "Client" in 232 [draft-davidson-pp-protocol]. Clients are assumed to only store data 233 related to the tokens that it has been issued by the server. This 234 storage is used for constructing redemption requests. 236 Clients MAY choose not to accept tokens from servers that they do not 237 trust. See Section 6 for a wider discussion. 239 3.2.1. Client identifying information 241 Privacy properties of this protocol do not take into account other 242 possibly identifying information available in an implementation, such 243 as a client's IP address. Servers which monitor IP addresses may use 244 this to track client redemption patterns over time. Clients cannot 245 check whether servers monitor such identifying information. Thus, 246 clients SHOULD minimize or remove identifying information where 247 possible, e.g., by using anonymity-preserving tools such as Tor to 248 interact with servers. 250 4. Key management framework 252 The key material and protocol configuration that a server uses to 253 issue tokens corresponds to a number of different pieces of 254 information. 256 * The ciphersuite that the server is using. 258 * The public keys that are active for the server. 260 For reasons that we address later in Section 7, the way that the 261 server publishes and maintains this information impacts the effective 262 privacy of the clients. In this section, we describe the main 263 policies that need to be satisfied for a key management system in a 264 Privacy Pass ecosystem. 266 Note that we only specify a set of guidelines and recommendations for 267 operating a public key registry in this document. Actual 268 specification of such a registry and how it operates will be covered 269 elsewhere. 271 4.1. Public key registries 273 Server's must provide their public keys to clients along with details 274 about the cryptographic ciphersuite that they are using. In 275 Section 7, we address the importance of providing clients with 276 sources of truth for learning the server's key configuration. 278 In particular, server key material MUST be publicly available in a 279 tamper-proof data structure, which we refer to as a key registry. A 280 registry must be globally consistent. Clients using the same 281 registry should coordinate in some way to ensure they have a 282 consistent view of said registry. This can be done via gossiping or 283 some other mechanism. The exact mechanism for this coordination will 284 be described elsewhere. It is assumed there will be at least one 285 such mechanism. 287 It is RECOMMENDED that each key registry is an append-only data 288 structure, such as a Merkle Tree. The key registry should be 289 operated independently of any server that publishes key material to 290 the registry. This ensures that any client can make better 291 judgements on whether to trust the registry and, transitively, each 292 server. 294 +--------------------------------------------------------+ 295 | | 296 | Ecosystem +---+ | 297 | | C | | 298 | +--------------+ <------ pkS1 ----> +---+ | 299 | | Registry 1 | | 300 | ++-------------+ <-------------- pkS1 --------> +---+ | 301 | | | C | | 302 | | +--------------+ <--------- pkS3 --------> +---+ | 303 | | | Registry 2 | | 304 | pkS1 +----^-------^-+ <--------- pkS2 --------> +---+ | 305 | | | | | C | | 306 | | pkS2 pkS3 +---+ | 307 | | | | | 308 | ++---+ +-+--+ +-+--+ | 309 | | S1 | | S2 | | S3 | | 310 | +----+ +----+ +----+ | 311 | | 312 +--------------------------------------------------------+ 314 While there may be multiple key registries for a given ecosystem, a 315 server MUST only publish its key material to a single registry. This 316 ensures that the server is keeping a consistent view of its key 317 material. 319 4.2. Key rotation 321 Token issuance associates all issued tokens with a particular choice 322 of key. If a server issues tokens with many keys, then this may harm 323 the anonymity of the Client. For example, they would be able to map 324 the Client's access patterns by inspecting which key each token they 325 possess has been issued under. 327 To prevent against this, servers MUST only use one private key for 328 issuing tokens at any given time. Servers may use two or more keys 329 for redemption to allow servers for seamless key rotation. 331 Key rotations must be limited in frequency for similar reasons. See 332 Section 9 for guidelines on what frequency of key rotations are 333 permitted. 335 4.3. Ciphersuites 337 Since a server is only permitted to have a single active issuing key, 338 this implies that only a single ciphersuite is allowed per issuance 339 period. If a server wishes to change their ciphersuite, they MUST do 340 so during a key rotation. 342 5. Server running modes 344 We provide an overview of some of the possible frameworks for 345 configuring the way that servers run in the Privacy Pass ecosystem. 346 In short, servers may be configured to provide symmetric issuance and 347 redemption with clients. While some servers may be configured as 348 proxies that accept Privacy Pass data and send it to another server 349 that actually processes issuance or redemption data. Finally, we 350 also consider instances of the protocol that may permit public 351 verification. 353 The intention with providing each of these running modes is to cover 354 the different applications that utilize variants of the Privacy Pass 355 protocol. We RECOMMEND that any Privacy Pass server implementation 356 adheres to one of these frameworks. 358 5.1. Single-Verifier 360 The simplest way of considering the Privacy Pass protocol is in a 361 setting where the same server plays the role of server and verifier, 362 we call this "Single-Verifier" (SV). 364 Let S be the server, and C be the client. When S wants to issue 365 tokens to C, they invoke the issuance protocol where C generates 366 their own inputs, and S uses their secret key skS. In this setting, 367 C can only perform token redemption with S. When a token redemption 368 is required, C and S invoke the redemption phase of the protocol, 369 where C uses an issued token from a previous exchange, and S uses skS 370 to validate the redemption. 372 5.2. Delegated-Verifier 374 In this setting, each client C obtains issued tokens from a derver S 375 via the issuance phase of the protocol. The difference is that C can 376 prove that they hold a valid authorization with any verifier V. We 377 still only consider S to hold their own secret key. We name this 378 mode "Delegated-Verifier" (DV). 380 When C interacts with V, V can ask C to provide proof of 381 authorization to the separate server S. The first stage of the 382 redemption phase of the protocol is invoked between C and V, which 383 sees C send an unused redemption token to V. This message is then 384 used in a redemption exchange between V and S, where V plays the role 385 of the Client. Then S sends the result of the redemption 386 verification to V, and V uses this result to determine whether C has 387 a valid token. 389 5.3. Asynchronous-Verifier 391 This setting is inspired by recently proposed APIs such as 392 [TrustTokenAPI]. It is similar to the DV configuration, except that 393 the verifiers V no longer interact with the server S. Only C 394 interacts with S, and this is done asynchronously to the 395 authorization request from V. Hence "Asynchronous-Verifier" (AV). 397 When V invokes a redemption for C, C then invokes a redemption 398 exchange with S in a separate session. If verification is carried 399 out successfully by S, S instead returns a Signed Redemption Record 400 (SRR) that contains the following information: 402 "result": { 403 "timestamp":"2019-10-09-11:06:11", 404 "verifier": "V", 405 }, 406 "signature":sig, 408 The "signature" field carries a signature evaluated over the contents 409 of "result" using a long-term signing key for the server S, of which 410 the corresponding public key is well-known to C and V. This would 411 need to be published alongside other public key data for S. Then C 412 can prove that they hold a valid authorization from S to V by sending 413 the SRR to V. The SRR can be verified by V by verifying the 414 signature, using the well-known public key for S. 416 Such records can be cached to display again in the future. The 417 server can also add an expiry date to the record to determine when 418 the client must refresh the record. 420 5.4. Public-Verifier 422 We consider the case where client redemptions can be verified 423 publicly using the server public key. This allows for defining 424 extensions of Privacy Pass that use public-key cryptography to allow 425 public verification. 427 In this case, the client C obtains a redemption token from S. The 428 redemption token is publicly verifiable in the sense that any entity 429 that knows the public key for S can verify the token. This running 430 mode is known as "Public-Verifier" (PV). 432 5.5. Bounded number of servers 434 Each of the configurations above can be generalized to settings where 435 a bounded number of servers are allowed, and verifiers can invoke 436 authorization verification for any of the available servers. 438 As we will discuss later in Section 7, configuring a large number of 439 servers can lead to privacy concerns for the clients in the 440 ecosystem. Therefore, we are careful to ensure that the number of 441 servers is kept strictly bounded. The actual servers can be replaced 442 with different servers as long as the total never exceeds this bound. 443 Moreover, server replacements also have an effect on client anonymity 444 that is similar to when a key rotation occurs. server so replacement 445 should only be permitted at similar intervals. 447 See Section 7 for more details about maintaining privacy with 448 multiple servers. 450 6. Client-Server trust relationship 452 It is important, based on the architecture above, that any client can 453 determine whether it would like to interact with a given server in 454 the ecosystem. Note that this decision must be taken before a client 455 issues a valid redemption to the server, since redemptions reveal the 456 anonymity set that the client belongs to. 458 This judgement can be based on a multitude of factors, associated 459 with the way that a server presents itself in the ecosystem. A non- 460 exhaustive list of server characteristics that a client MAY want to 461 check are the following. 463 * Which key registry a server posts their key updates to. 465 * How frequent key updates are issued, and which ciphersuite they 466 use. 468 * The reason given to initiate the redemption. 470 To aid client trust decisions, a server can publish a "Privacy Pass 471 policy" that documents the procedures that the server uses to ensure 472 that client privacy is respected. If a server does not publish such 473 a document then the client may choose to use its own judgement, or to 474 reject the server altogether. 476 It should be noted that the client trust decision can be made apriori 477 by specifying an allow-list of all servers that it accepts tokens 478 from. This means that these checks do not have to be performed 479 online. 481 7. Privacy considerations 483 In the Privacy Pass protocol [draft-davidson-pp-protocol], redemption 484 tokens intentionally encode very little information beyond which key 485 was used to sign them. The protocol intentionally uses components 486 that provide cryptographic guarantees of this fact. However, even 487 with these guarantees, the way that the ecosystem is constructed can 488 be used to identify clients based on this limited information. 490 The goal of the Privacy Pass ecosystem is to construct an environment 491 that can easily measure (and maximize) the relative anonymity of any 492 client that is part of it. An inherent feature of being part of this 493 ecosystem is that any client can only remain private relative to the 494 entire space of users using the protocol. Moreover, by owning tokens 495 for a given set of keys, the client's anonymity set shrinks to the 496 total number of clients controlling tokens for the same keys. 498 In the following, we consider the possible ways that servers and 499 servers can leverage their position to try and reduce the anonymity 500 sets that clients belong to (or, user segregation). For each case, 501 we provide mitigations that the Privacy Pass ecosystem must implement 502 to prevent these actions. 504 7.1. Server key rotation 506 Techniques to introduce client "segregation" can be used to reduce 507 client anonymity. Such techniques are closely linked to the type of 508 key schedule that is used by the server. When a server rotates their 509 key, any client that invokes the issuance protocol in this key cycle 510 will be part of a group of possible clients owning valid tokens for 511 this key. To mechanize this attack strategy, a server could 512 introduce a key rotation policy that forces clients into small key 513 cycles. Thus, reducing the size of the anonymity set for these 514 clients. 516 We RECOMMEND that servers should only invoke key rotation for fairly 517 large periods of time such as between 1 and 12 weeks. Key rotations 518 represent a trade-off between client privacy and continued server 519 security. Therefore, it is still important that key rotations occur 520 on a fairly regular cycle to reduce the harmfulness of a server key 521 compromise. 523 With an active user-base, a week gives a fairly large window for 524 clients to participate in the Privacy Pass protocol and thus enjoy 525 the anonymity guarantees of being part of a larger group. The low 526 ceiling of 12 weeks prevents a key compromise from being too 527 destructive. If a server realizes that a key compromise has occurred 528 then the server should sample a new key, and upload the public key to 529 the key registry; invoking any revocation procedures that may apply 530 for the old key. 532 7.2. Large numbers of servers 534 Similarly to the server rotation dynamic that is raised above, if 535 there are a large number of servers then segregation can occur. In 536 the FV, AV and PV running modes (Section 5), a verifier OV can 537 trigger redemptions for any of the available servers. Each 538 redemption token that a client holds essentially corresponds to a bit 539 of information about the client that OV can learn. Therefore, there 540 is an exponential loss in anonymity relative to the number of servers 541 that there are. 543 For example, if there are 32 servers, then OV learns 32 bits of 544 information about the client. If the distribution of server trust is 545 anything close to a uniform distribution, then this is likely to 546 uniquely identify any client amongst all other Internet users. 547 Assuming a uniform distribution is clearly the worst-case scenario, 548 and unlikely to be accurate, but it provides a stark warning against 549 allowing too many servers at any one time. 551 In cases where clients can hold tokens for all servers at any given 552 time, a strict bound SHOULD be applied to the active number of 553 servers in the ecosystem. We propose that allowing no more than 4 554 servers at any one time is highly preferable (leading to a maximum of 555 64 possible user segregations). However, as highlighted in 556 Section 9, having a very large user base (> 5 million users), could 557 potentially allow for larger values. server replacements should only 558 occur with the same frequency as config rotations as they can lead to 559 similar losses in anonymity if clients still hold redemption tokens 560 for previously active servers. 562 In addition, we RECOMMEND that trusted registries indicate at all 563 times which servers are deemed to be active. If a client is asked to 564 invoke any Privacy Pass exchange for an server that is not declared 565 active, then the client SHOULD refuse to retrieve the server 566 configuration during the protocol. 568 7.2.1. Allowing larger number of servers 570 The bounds on the numbers of servers that we proposed above are very 571 restrictive. This is due to the fact that we considered a situation 572 where a client could be issued (and forced to redeem) tokens for any 573 issuing key. 575 An alternative system is to ensure a robust strategy for ensuring 576 that clients only possess redemption tokens for a similarly small 577 number of servers at any one time. This prevents a malicious 578 verifier from being able to invoke redemptions for many servers since 579 the client would only be holding redemption tokens for a small set of 580 servers. When a client is issued tokens from a new server and 581 already has tokens from the maximum number of servers, it simply 582 deletes the oldest set of redemption tokens in storage and then 583 stores the newly acquired tokens. 585 For example, if clients ensure that they only hold redemption tokens 586 for 4 servers, then this increases the potential size of the 587 anonymity sets that the client belongs to. However, this doesn't 588 protect clients completely as it would if only 4 servers were 589 permitted across the whole system. For example, these 4 servers 590 could be different for each client. Therefore, the selection of 591 servers they possess tokens for is still revealing. Understanding 592 this trade-off is important in deciding the effective anonymity of 593 each client in the system. 595 7.3. Partitioning of server key material 597 If there are multiple key registries, or if a key registry colludes 598 with an server, then it is possible to provide a split-view of an 599 server's key material to different clients. This would involve 600 posting different key material in different locations, or actively 601 modifying the key material at a given location. 603 Key registries should operate independently of server's in the 604 ecosystem, and within the guidelines stated in Section 4. Any client 605 should follow the recommendations in Section 6 for determining 606 whether an server and its key material should be trusted. 608 7.4. Additional token metadata 610 In [draft-davidson-pp-protocol], it is permissible to add public and 611 private metadata bits to redemption tokens. The core protocol 612 instantiation that is described does not include additional metadata. 613 However, future instantiations may use this functionality to provide 614 redemption verifiers with additional information about the user. 616 Note that any arbitrary bits of information can be used to further 617 segment the size of the user's anonymity set. Any server that wanted 618 to track a single user could add a single metadata bit to user 619 tokens. For the tracked user it would set the bit to "1", and "0" 620 otherwise. Adding additional bits provides an exponential increase 621 in tracking granularity similarly to introducing more servers (though 622 with more potential targeting). 624 For this reason, the amount of metadata used by an server in creating 625 redemption tokens must be taken into account - together with the bits 626 of information that server's may learn about clients otherwise. We 627 discuss this more in Section 9. 629 7.5. Tracking and identity leakage 631 Privacy losses may be encountered if too many redemptions are allowed 632 in a short burst. For instance, in the Internet setting, this may 633 allow delegated or asynchronous verifiers to learn more information 634 from the metadata that the client may hold (such as first-party 635 cookies for other domains). Mitigations for this issue are similar 636 to those proposed in Section 7.2 for tackling the problem of having 637 large number of servers. 639 In AV, cached SRRs and their associated server public keys have a 640 similar tracking potential to first party cookies in the browser 641 setting. These considerations will be covered in a separate 642 document, detailing Privacy Pass protocol integration into the wider 643 web architecture [draft-svaldez-pp-http-api]. 645 7.6. Client incentives for anonymity reduction 647 Clients may see an incentive in accepting all tokens that are issued 648 by a server, even if the tokens fail later verification checks. This 649 is because tokens effectively represent a form of currency that they 650 can later redeem for some sort of benefit. The verification checks 651 that are put in place are there to ensure that the client does not 652 sacrifice their anonymity. However, a client may judge the 653 "monetary" benefit of owning tokens to be greater than their own 654 privacy. 656 Firstly, a client behaving in this way would not be compliant with 657 the protocol, as laid out in [draft-davidson-pp-protocol]. 659 Secondly, acting in this way only affects the privacy of the 660 immediate client. There is an exception if a large number of clients 661 colluded to accept bad data, then any client that didn't accept would 662 be part of a smaller anonymity set. However, such a situation would 663 be identical to the situation where the total number of clients in 664 the ecosystem is small. Therefore, the reduction in the size of the 665 anonymity set would be equivalent; see Section 7.2 for more details. 667 8. Security considerations 669 We present a number of security considerations that prevent malicious 670 clients from abusing the protocol. 672 8.1. Double-spend protection 674 All issuing server should implement a robust storage-query mechanism 675 for checking that tokens sent by clients have not been spent before. 676 Such tokens only need to be checked for each server individually. 677 But all servers must perform global double-spend checks to avoid 678 clients from exploiting the possibility of spending tokens more than 679 once against distributed token checking systems. For the same 680 reason, the global data storage must have quick update times. While 681 an update is occurring it may be possible for a malicious client to 682 spend a token more than once. 684 8.2. Token exhaustion 686 When a client holds tokens for an server, it is possible for any 687 verifier to invoke that client to redeem tokens for that server. 688 This can lead to an attack where a malicious verifier can force a 689 client to spend all of their tokens for a given server. To prevent 690 this from happening, methods should be put into place to prevent many 691 tokens from being redeemed at once. 693 For example, it may be possible to cache a redemption for the entity 694 that is invoking a token redemption. If the verifier requests more 695 tokens then the client simply returns the cached token that it 696 returned previously. This could also be handled by simply not 697 redeeming any tokens for verification if a redemption had already 698 occurred in a given time window. 700 In AV, the client instead caches the SRR that it received in the 701 asynchronous redemption exchange with the server. If the same 702 verifier attempts another redemption request, then the client simply 703 returns the cached SRR. The SRRs can be revoked by the server, if 704 need be, by providing an expiry date or by signaling that records 705 from a particular window need to be refreshed. 707 8.3. Avoiding server centralization 709 [[OPEN ISSUE: explain potential and mitigations for server 710 centralization]] 712 9. Protocol parametrization 714 We provide a summary of the parameters that we use in the Privacy 715 Pass protocol ecosystem. These parameters are informed by both 716 privacy and security considerations that are highlighted in Section 7 717 and Section 8, respectively. These parameters are intended as a 718 single reference point for those implementing the protocol. 720 Firstly, let U be the total number of users, I be the total number of 721 servers. We let M be the total number of metadata bits that are 722 allowed to be added by any given server. Assuming that each user 723 accept tokens from a uniform sampling of all the possible servers, as 724 a worst-case analysis, this segregates users into a total of 2^I 725 buckets. As such, we see an exponential reduction in the size of the 726 anonymity set for any given user. This allows us to specify the 727 privacy constraints of the protocol below, relative to the setting of 728 A. 730 +------------------------------------------+------------------+ 731 | parameter | value | 732 +==========================================+==================+ 733 | Minimum anonymity set size (A) | 5000 | 734 +------------------------------------------+------------------+ 735 | Recommended key lifetime (L) | 2 - 24 weeks | 736 +------------------------------------------+------------------+ 737 | Recommended key rotation frequency (F) | L/2 | 738 +------------------------------------------+------------------+ 739 | Maximum additional metadata bits (M) | 1 | 740 +------------------------------------------+------------------+ 741 | Maximum allowed servers (I) | (log_2(U/A)-1)/2 | 742 +------------------------------------------+------------------+ 743 | Maximum active issuance keys | 1 | 744 +------------------------------------------+------------------+ 745 | Maximum active redemption keys | 2 | 746 +------------------------------------------+------------------+ 747 | Minimum cryptographic security parameter | 128 bits | 748 +------------------------------------------+------------------+ 750 Table 1 752 9.1. Justification 754 We make the following assumptions in these parameter choices. 756 * Inferring the identity of a user in a 5000-strong anonymity set is 757 difficult. 759 * After 2 weeks, all clients in a system will have rotated to the 760 new key. 762 In terms of additional metadata, the only concrete applications of 763 Privacy Pass that use additional metadata require just a single bit. 764 Therefore, we set the ceiling of permitted metadata to 1 bit for now, 765 this may be revisited in future revisions. 767 The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. 768 This is derived from the fact that permitting I servers lead to 2^I 769 segregations of the total user-base U. Moreover, if we permit M = 1, 770 then this effectively halves the anonymity set for each server, and 771 thus we incur a factor of 2I in the exponent. By reducing I, we 772 limit the possibility of performing the attacks mentioned in 773 Section 7. 775 We must also account for each user holding issued data for more then 776 one possible active keys. While this may also be a vector for 777 monitoring the access patterns of clients, it is likely to 778 unavoidable that clients hold valid issuance data for the previous 779 key epoch. This also means that the server can continue to verify 780 redemption data for a previously used key. This makes the rotation 781 period much smoother for clients. 783 For privacy reasons, it is recommended that key epochs are chosen 784 that limit clients to holding issuance data for a maximum of two 785 keys. By choosing F = L/2 then the minimum value of F is a week, 786 since the minimum recommended value of L is 2 weeks. Therefore, by 787 the initial assumption, then all users should only have access to 788 only two keys at any given time. This reduces the anonymity set by 789 another half at most. 791 Finally, the minimum security parameter size is related to the 792 cryptographic security offered by the protocol that is run. This 793 parameter corresponds to the number of operations that any adversary 794 has in breaking one of the security guarantees in the Privacy Pass 795 protocol [draft-davidson-pp-protocol]. 797 9.2. Example parameterization 799 Using the specification above, we can give some example 800 parameterizations. For example, the current Privacy Pass browser 801 extension [PPEXT] has nearly 300000 active users (from Chrome and 802 Firefox). As a result, log_2(U/A) is approximately 6 and so the 803 maximum value of I should be 3. 805 If the value of U is much bigger (e.g. 5 million) then this would 806 permit I = (log_2(5000000/5000)-1)/2 ~= 4 servers. 808 9.3. Allowing more servers 810 Using the recommendations in Section 7.2.1, it is possible to 811 tolerate larger number of servers if clients in the ecosystem ensure 812 that they only store tokens for a small number of them. In 813 particular, if clients limit their storage of redemption tokens to 814 the bound implied by I, then prevents a malicious verifier from 815 triggering redemptions for all servers in the ecosystem. 817 10. Extension integration policy 819 The Privacy Pass protocol and ecosystem are both intended to be 820 receptive to extensions that expand the current set of functionality. 821 As specified in [draft-davidson-pp-protocol], all extensions to the 822 Privacy Pass protocol SHOULD be specified as separate documents that 823 modify the content of this document in some way. We provide guidance 824 on the type of modifications that are possible in the following. 826 Any such extension should also come with a detailed analysis of the 827 privacy impacts of the extension, why these impacts are justified, 828 and guidelines on changes to the parametrization in Section 9. 829 Similarly, extensions MAY also add new server running modes, if 830 applicable, to those that are documented in Section 5. 832 Any extension to the Privacy Pass protocol must adhere to the 833 guidelines specified in Section 4 for managing server public key 834 data. 836 11. Existing applications 838 The following is a non-exhaustive list of applications that currently 839 make use of the Privacy Pass protocol, or some variant of the 840 underlying functionality. 842 11.1. Cloudflare challenge pages 844 Cloudflare uses an implementation of the Privacy Pass protocol for 845 allowing clients that have previously interacted with their Internet 846 challenge protection system to bypass future challenges [PPSRV]. 847 These challenges can be expensive for clients, and there have been 848 cases where bugs in the implementations can severely degrade client 849 accessibility. 851 Clients must install a browser extension [PPEXT] that acts as the 852 Privacy Pass client in an exchange with Cloudflare's Privacy Pass 853 server, when an initial challenge solution is provided. The client 854 extension stores the issued tokens and presents a valid redemption 855 token when it sees future Cloudflare challenges. If the redemption 856 token is verified by the server, the client passes through the 857 security mechanism without completing a challenge. 859 11.2. Trust Token API 861 The Trust Token API [TrustTokenAPI] has been devised as a generic API 862 for providing Privacy Pass functionality in the browser setting. The 863 API is intended to be implemented directly into browsers so that 864 server's can directly trigger the Privacy Pass workflow. 866 11.3. Zero-knowledge Access Passes 868 The PrivateStorage API developed by Least Authority is a solution for 869 uploading and storing end-to-end encrypted data in the cloud. A 870 recent addition to the API [PrivateStorage] allows clients to 871 generate Zero-knowledge Access Passes (ZKAPs) that the client can use 872 to show that it has paid for the storage space that it is using. The 873 ZKAP protocol is based heavily on the Privacy Pass redemption 874 mechanism. The client receives ZKAPs when it pays for storage space, 875 and redeems the passes when it interacts with the PrivateStorage API. 877 11.4. Basic Attention Tokens 879 The browser Brave uses Basic Attention Tokens (BATs) to provide the 880 basis for an anonymity-preserving rewards scheme [Brave]. The BATs 881 are essentially Privacy Pass redemption tokens that are provided by a 882 central Brave server when a client performs some action that triggers 883 a reward event (such as watching an advertisement). When the client 884 amasses BATs, it can redeem them with the Brave central server for 885 rewards. 887 11.5. Token Based Services 889 Similarly to BATs, a more generic approach for providing anonymous 890 peers to purchase resources from anonymous servers has been proposed 891 [OpenPrivacy]. The protocol is based on a variant of Privacy Pass 892 and is intended to allow clients purchase (or pre-purchase) services 893 such as message hosting, by using Privacy Pass redemption tokens as a 894 form of currency. This is also similar to how ZKAPs are used. 896 12. References 898 12.1. Normative References 900 [draft-davidson-pp-protocol] 901 Davidson, A., "Privacy Pass: The Protocol", n.d., 902 . 905 [draft-svaldez-pp-http-api] 906 Valdez, S., "Privacy Pass: HTTP API", n.d., 907 . 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, 912 DOI 10.17487/RFC2119, March 1997, 913 . 915 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 916 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 917 . 919 12.2. Informative References 921 [Brave] "Brave Rewards", n.d., . 923 [OpenPrivacy] 924 "Token Based Services - Differences from PrivacyPass", 925 n.d., . 928 [PPEXT] "Privacy Pass Browser Extension", n.d., 929 . 932 [PPSRV] Sullivan, N., "Cloudflare Supports Privacy Pass", n.d., 933 . 936 [PrivateStorage] 937 Steininger, L., "The Path from S4 to PrivateStorage", 938 n.d., . 941 [TrustTokenAPI] 942 Google, ., "Getting started with Trust Tokens", n.d., 943 . 945 Appendix A. Contributors 947 * Alex Davidson (alex.davidson92@gmail.com) 949 * Christopher Wood (caw@heapingbits.net) 951 Author's Address 952 Alex Davidson 953 Cloudflare Portugal 954 Largo Rafael Bordalo Pinheiro 29 955 Lisbon 956 Portugal 958 Email: alex.davidson92@gmail.com