idnits 2.17.1 draft-ietf-privacypass-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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 (19 February 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ietf-privacypass-http-api-00 == Outdated reference: A later version (-16) exists of draft-ietf-privacypass-protocol-00 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Davidson 3 Internet-Draft LIP 4 Intended status: Informational C.A. Wood 5 Expires: 23 August 2021 Cloudflare 6 19 February 2021 8 Privacy Pass Architectural Framework 9 draft-ietf-privacypass-architecture-01 11 Abstract 13 This document specifies the architectural framework for constructing 14 secure and anonymity-preserving instantiations of the Privacy Pass 15 protocol. It provides recommendations on how the protocol ecosystem 16 should be constructed to ensure the privacy of clients, and the 17 security of all participating entities. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on 23 August 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 43 license-info) in effect on the date of publication of this document. 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License text 47 as described in Section 4.e of the Trust Legal Provisions and are 48 provided without warranty as described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Ecosystem participants . . . . . . . . . . . . . . . . . . . 4 55 3.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 3.2.1. Client identifying information . . . . . . . . . . . 6 58 4. Key management and discovery . . . . . . . . . . . . . . . . 6 59 4.1. Key rotation . . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . 8 61 5. Server running modes . . . . . . . . . . . . . . . . . . . . 8 62 5.1. Single-Verifier . . . . . . . . . . . . . . . . . . . . . 8 63 5.2. Delegated-Verifier . . . . . . . . . . . . . . . . . . . 8 64 5.3. Asynchronous-Verifier . . . . . . . . . . . . . . . . . . 9 65 5.4. Public-Verifier . . . . . . . . . . . . . . . . . . . . . 9 66 5.5. Bounded number of servers . . . . . . . . . . . . . . . . 10 67 6. Metadata . . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.1. Client privacy implications . . . . . . . . . . . . . . . 11 69 7. Client-Server trust relationship . . . . . . . . . . . . . . 11 70 8. Privacy considerations . . . . . . . . . . . . . . . . . . . 12 71 8.1. Server key rotation . . . . . . . . . . . . . . . . . . . 12 72 8.2. Large numbers of servers . . . . . . . . . . . . . . . . 13 73 8.2.1. Allowing larger number of servers . . . . . . . . . . 14 74 8.3. Partitioning of server key material . . . . . . . . . . . 14 75 8.4. Tracking and identity leakage . . . . . . . . . . . . . . 15 76 8.5. Client incentives for anonymity reduction . . . . . . . . 15 77 9. Security considerations . . . . . . . . . . . . . . . . . . . 15 78 9.1. Double-spend protection . . . . . . . . . . . . . . . . . 16 79 9.2. Token exhaustion . . . . . . . . . . . . . . . . . . . . 16 80 9.3. Avoiding server centralization . . . . . . . . . . . . . 16 81 10. Protocol parametrization . . . . . . . . . . . . . . . . . . 16 82 10.1. Justification . . . . . . . . . . . . . . . . . . . . . 17 83 10.2. Example parameterization . . . . . . . . . . . . . . . . 18 84 10.3. Allowing more servers . . . . . . . . . . . . . . . . . 19 85 11. Extension integration policy . . . . . . . . . . . . . . . . 19 86 12. Existing applications . . . . . . . . . . . . . . . . . . . . 19 87 12.1. Cloudflare challenge pages . . . . . . . . . . . . . . . 19 88 12.2. Trust Token API . . . . . . . . . . . . . . . . . . . . 20 89 12.3. Zero-knowledge Access Passes . . . . . . . . . . . . . . 20 90 12.4. Basic Attention Tokens . . . . . . . . . . . . . . . . . 20 91 12.5. Token Based Services . . . . . . . . . . . . . . . . . . 20 92 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 93 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 94 13.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 98 1. Introduction 100 The Privacy Pass protocol provides an anonymity-preserving mechanism 101 for authorization of clients with servers. The protocol is detailed 102 in [I-D.ietf-privacypass-protocol] and is intended for use in the 103 application-layer. 105 The way that the ecosystem around the protocol is set up can have 106 significant impacts on the stated privacy and security guarantees of 107 the protocol. For instance, the number of servers issuing Privacy 108 Pass tokens, along with the number of registered clients, determines 109 the anonymity set of each individual client. Moreover, this can be 110 influenced by other factors, such as: the key rotation policy used by 111 each server; and, the number of supported ciphersuites. There are 112 also client behavior patterns that can reduce the effective security 113 of the server. 115 In this document, we will provide a structural framework for building 116 the ecosystem around the Privacy Pass protocol. The core of the 117 document also includes policies for the following considerations. 119 * How server key material should be managed and accessed. 121 * Compatible server issuance and redemption running modes and 122 associated expectations. 124 * How clients should evaluate server trust relationships. 126 * Security and privacy properties of the protocol. 128 * A concrete assessment and parametrization of the privacy budget 129 associated with different settings of the above policies. 131 * The incorporation of potential extensions into the wider 132 ecosystem. 134 Finally, we will discuss existing applications that make use of the 135 Privacy Pass protocol, and highlight how these may fit with the 136 proposed framework. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [RFC2119]. 144 The following terms are used throughout this document. 146 * Server: An entity that issues anonymous tokens to clients. In 147 symmetric verification cases, the server must also verify tokens. 148 Also referred to as the server. 150 * Client: An entity that seeks authorization from a server. 152 We assume that all protocol messages are encoded into raw byte format 153 before being sent. We use the TLS presentation language [RFC8446] to 154 describe the structure of the data that is communicated and stored. 156 3. Ecosystem participants 158 The Privacy Pass ecosystem refers to the global framework in which 159 multiple instances of the Privacy Pass protocol operate. This refers 160 to all servers that support the protocol, or any extension of it, 161 along with all of the clients that may interact with these servers. 163 The ecosystem itself, and the way it is constructed, is critical for 164 evaluating the privacy of each individual client. We assume that a 165 client's privacy refers to fraction of users that it represents in 166 the anonymity set that it belongs to. We discuss this more in 167 Section 8. 169 +-----------------------------------------------------+ 170 | | 171 | Ecosystem | 172 | | 173 | | 174 | | 175 | +-----+ | 176 | | | +-----+ | 177 | | C1 | <--------------------> | | | 178 | | | | S1 | | 179 | +-----+ +-------------> | | | 180 | | +-----+ | 181 | | | 182 | +-----+ | | 183 | | | <------+ | 184 | | C2 | | 185 | | | <------+ +-----+ | 186 | +-----+ +-------------> | | | 187 | | S2 | | 188 | +-------------> | | | 189 | +-----+ | +-----+ | 190 | | | | | 191 | | C3 | <------+ | 192 | | | | 193 | +-----+ | 194 | | 195 +-----------------------------------------------------+ 197 In the above diagram, the arrows indicate the open channels between a 198 client and a server. An open channel indicates that a client accepts 199 Privacy Pass tokens from this server. 201 If no channel exists, this means that the client chooses not to 202 accept tokens from (or redeem tokens with) that particular server. 203 We discuss the roles of servers and clients further in Section 3.1 204 and Section 3.2, respectively. 206 3.1. Servers 208 Generally, servers in the Privacy Pass ecosystem are entities whose 209 primary function is to undertake the role of the "server" in 210 [I-D.ietf-privacypass-protocol]. To facilitate this, the server MUST 211 hold a Privacy Pass protocol keypair at any given time. The server 212 public key MUST be made available to all clients in such a way that 213 key rotations and other updates are publicly visible. The server MAY 214 also require additional state for ensuring this. We provide a wider 215 discussion in Section 4. 217 Note that, in the core protocol instantiation from 218 [I-D.ietf-privacypass-protocol], the redemption phase is a symmetric 219 protocol. This means that the server is the same server that 220 ultimately processes token redemptions from clients. However, 221 plausible extensions to the protocol specification may allow public 222 verification of tokens by entities which do not hold the secret 223 Privacy Pass keying material. We highlight possible client and 224 server configurations in Section 5. 226 The server must be uniquely identifiable by all clients with a 227 consistent identifier. 229 3.2. Clients 231 Clients in the Privacy Pass ecosystem are entities whose primary 232 function is to undertake the role of the "Client" in 233 [I-D.ietf-privacypass-protocol]. Clients are assumed to only store 234 data related to the tokens that it has been issued by the server. 235 This storage is used for constructing redemption requests. 237 Clients MAY choose not to accept tokens from servers that they do not 238 trust. See Section 7 for a wider discussion. 240 3.2.1. Client identifying information 242 Privacy properties of this protocol do not take into account other 243 possibly identifying information available in an implementation, such 244 as a client's IP address. Servers which monitor IP addresses may use 245 this to track client redemption patterns over time. Clients cannot 246 check whether servers monitor such identifying information. Thus, 247 clients SHOULD minimize or remove identifying information where 248 possible, e.g., by using anonymity-preserving tools such as Tor to 249 interact with servers. 251 4. Key management and discovery 253 The key material and protocol configuration that a server uses to 254 issue tokens corresponds to a number of different pieces of 255 information. 257 * The ciphersuite that the server is using. 259 * The public keys that are active for the server. 261 The way that the server publishes and maintains this information 262 impacts the effective privacy of the clients; see Section 8 for more 263 details. The fundamental requirement for key management and 264 discovery is that servers must be unable to target specific clients 265 with unique keys without detection. There are a number of ways in 266 which this might be implemented: 268 * Servers use a verifiable, tamper-free registry from which clients 269 discover keys. Similar to related mechanisms and protocols such 270 as Certificate Transparency [RFC6962], this may require external 271 auditors or additional client behavior to ensure the registry 272 state is consistent for all clients. 274 * Clients use an anonymity-preserving tool such as Tor to discover 275 keys from multiple network vantage points. This is done to ensure 276 consistent keys to seemingly different clients. 278 * Clients embed server keys into software. 280 Specific mechanisms for key management and discovery are out of scope 281 for this document. 283 4.1. Key rotation 285 Token issuance associates all issued tokens with a particular choice 286 of key. If a server issues tokens with many keys, then this may harm 287 the anonymity of the Client. For example, they would be able to map 288 the Client's access patterns by inspecting which key each token they 289 possess has been issued under. 291 To prevent against this, servers MUST only use one private key for 292 issuing tokens at any given time. Servers MAY use one or more keys 293 for redemption to allow servers for seamless key rotation. 295 Servers may rotate keys as a means of revoking tokens issued under 296 old or otherwise expired keys. Alternatively, servers may include 297 expiration information as metadata alongside the token; See Section 6 298 for more discussion about metadata constraints. Both techinques are 299 equivalent since they cryptographically bind expiration to individual 300 tokens. 302 Key rotations should be limited in frequency for similar reasons. 303 See Section 10 for guidelines on what frequency of key rotations are 304 permitted. 306 4.2. Ciphersuites 308 Since a server is only permitted to have a single active issuing key, 309 this implies that only a single ciphersuite is allowed per issuance 310 period. If a server wishes to change their ciphersuite, they MUST do 311 so during a key rotation. 313 5. Server running modes 315 We provide an overview of some of the possible frameworks for 316 configuring the way that servers run in the Privacy Pass ecosystem. 317 In short, servers may be configured to provide symmetric issuance and 318 redemption with clients. While some servers may be configured as 319 proxies that accept Privacy Pass data and send it to another server 320 that actually processes issuance or redemption data. Finally, we 321 also consider instances of the protocol that may permit public 322 verification. 324 The intention with providing each of these running modes is to cover 325 the different applications that utilize variants of the Privacy Pass 326 protocol. We RECOMMEND that any Privacy Pass server implementation 327 adheres to one of these frameworks. 329 5.1. Single-Verifier 331 The simplest way of considering the Privacy Pass protocol is in a 332 setting where the same server plays the role of server and verifier, 333 we call this "Single-Verifier" (SV). 335 Let S be the server, and C be the client. When S wants to issue 336 tokens to C, they invoke the issuance protocol where C generates 337 their own inputs, and S uses their secret key skS. In this setting, 338 C can only perform token redemption with S. When a token redemption 339 is required, C and S invoke the redemption phase of the protocol, 340 where C uses an issued token from a previous exchange, and S uses skS 341 to validate the redemption. 343 5.2. Delegated-Verifier 345 In this setting, each client C obtains issued tokens from a derver S 346 via the issuance phase of the protocol. The difference is that C can 347 prove that they hold a valid authorization with any verifier V. We 348 still only consider S to hold their own secret key. We name this 349 mode "Delegated-Verifier" (DV). 351 When C interacts with V, V can ask C to provide proof of 352 authorization to the separate server S. The first stage of the 353 redemption phase of the protocol is invoked between C and V, which 354 sees C send an unused redemption token to V. This message is then 355 used in a redemption exchange between V and S, where V plays the role 356 of the Client. Then S sends the result of the redemption 357 verification to V, and V uses this result to determine whether C has 358 a valid token. 360 5.3. Asynchronous-Verifier 362 This setting is inspired by recently proposed APIs such as 363 [TrustTokenAPI]. It is similar to the DV configuration, except that 364 the verifiers V no longer interact with the server S. Only C 365 interacts with S, and this is done asynchronously to the 366 authorization request from V. Hence "Asynchronous-Verifier" (AV). 368 When V invokes a redemption for C, C then invokes a redemption 369 exchange with S in a separate session. If verification is carried 370 out successfully by S, S instead returns a Signed Redemption Record 371 (SRR) that contains the following information: 373 "result": { 374 "timestamp":"2019-10-09-11:06:11", 375 "verifier": "V", 376 }, 377 "signature":sig, 379 The "signature" field carries a signature evaluated over the contents 380 of "result" using a long-term signing key for the server S, of which 381 the corresponding public key is well-known to C and V. This would 382 need to be published alongside other public key data for S. Then C 383 can prove that they hold a valid authorization from S to V by sending 384 the SRR to V. The SRR can be verified by V by verifying the 385 signature, using the well-known public key for S. 387 Such records can be cached to display again in the future. The 388 server can also add an expiry date to the record to determine when 389 the client must refresh the record. 391 5.4. Public-Verifier 393 We consider the case where client redemptions can be verified 394 publicly using the server public key. This allows for defining 395 extensions of Privacy Pass that use public-key cryptography to allow 396 public verification. 398 In this case, the client C obtains a redemption token from S. The 399 redemption token is publicly verifiable in the sense that any entity 400 that knows the public key for S can verify the token. This running 401 mode is known as "Public-Verifier" (PV). 403 5.5. Bounded number of servers 405 Each of the configurations above can be generalized to settings where 406 a bounded number of servers are allowed, and verifiers can invoke 407 authorization verification for any of the available servers. 409 As we will discuss later in Section 8, configuring a large number of 410 servers can lead to privacy concerns for the clients in the 411 ecosystem. Therefore, we are careful to ensure that the number of 412 servers is kept strictly bounded. The actual servers can be replaced 413 with different servers as long as the total never exceeds this bound. 414 Moreover, server replacements also have an effect on client anonymity 415 that is similar to when a key rotation occurs. 417 See Section 8 for more details about maintaining privacy with 418 multiple servers. 420 6. Metadata 422 Certain instantiations of Privacy Pass may permit public or private 423 metadata to be cryptographically bound to a token. As an example, 424 one trivial way to include public metadata is to assign a unique 425 issuer public key for each value of metadata, such that N keys yields 426 log2(N) bits of metadata. The total amount of metadata bits included 427 in a token is the sum of public and private metadata bits. See 428 Section 10 for discussion about metadata limits. 430 Public metadata is that which clients can observe as part of the 431 token issuance flow. Public metadata can either be transparent or 432 opaque. For example, transparent public metadata is a value that the 433 client either generates itself, or the server provides during the 434 issuance flow and the client can check for correctness. Opaque 435 public metadata is metadata the client can see but cannot check for 436 correctness. As an example, the opaque public metadata might be a 437 "fraud detection signal", computed on behalf of the server, during 438 token issuance. In normal circumstances, clients cannot determine if 439 this value is correct or otherwise a tracking vector. 441 Private metadata is that which clients cannot observe as part of the 442 token issuance flow. In [I-D.ietf-privacypass-protocol], it is 443 possible to include private metadata to redemption tokens. The core 444 protocol instantiation that is described does not include additional 445 metadata. However, future instantiations may use this functionality 446 to provide redemption verifiers with additional information about the 447 user. Such instantiations may be built on the Private Metadata Bit 448 construction from Kreuter et al. [KLOR20] or the attribute-based 449 VOPRF from Huang et al. [HIJK21]. 451 Metadata may also be arbitrarily long or bounded in length. The 452 amount of permitted metadata may be determined by application or by 453 the underlying cryptographic protocol. 455 6.1. Client privacy implications 457 Note that any metadata bits of information can be used to further 458 segment the size of the user's anonymity set. Any server that wanted 459 to track a single user could add a single metadata bit to user 460 tokens. For the tracked user it would set the bit to "1", and "0" 461 otherwise. Adding additional bits provides an exponential increase 462 in tracking granularity similarly to introducing more servers (though 463 with more potential targeting). 465 For this reason, the amount of metadata used by an server in creating 466 redemption tokens must be taken into account - together with the bits 467 of information that server's may learn about clients otherwise. 468 Since this metadata may be useful for practical deployments of 469 Privacy Pass, servers must balance this against the reduction in 470 client privacy. In general, servers should permit no more than 32 471 bits of metadata, as this can uniquely identify each possible user. 472 We discuss this more in Section 10. 474 7. Client-Server trust relationship 476 It is important, based on the architecture above, that any client can 477 determine whether it would like to interact with a given server in 478 the ecosystem. Note that this decision must be taken before a client 479 issues a valid redemption to the server, since redemptions reveal the 480 anonymity set that the client belongs to. 482 This judgement can be based on a multitude of factors, associated 483 with the way that a server presents itself in the ecosystem. A non- 484 exhaustive list of server characteristics that a client MAY want to 485 check are the following. 487 * Which key registry a server posts their key updates to. 489 * How frequent key updates are issued, and which ciphersuite they 490 use. 492 * The reason given to initiate the redemption. 494 To aid client trust decisions, a server can publish a "Privacy Pass 495 policy" that documents the procedures that the server uses to ensure 496 that client privacy is respected. If a server does not publish such 497 a document then the client may choose to use its own judgement, or to 498 reject the server altogether. 500 It should be noted that the client trust decision can be made apriori 501 by specifying an allow-list of all servers that it accepts tokens 502 from. This means that these checks do not have to be performed 503 online. 505 8. Privacy considerations 507 In the Privacy Pass protocol [I-D.ietf-privacypass-protocol], 508 redemption tokens intentionally encode very little information beyond 509 which key was used to sign them. The protocol intentionally uses 510 components that provide cryptographic guarantees of this fact. 511 However, even with these guarantees, the way that the ecosystem is 512 constructed can be used to identify clients based on this limited 513 information. 515 The goal of the Privacy Pass ecosystem is to construct an environment 516 that can easily measure (and maximize) the relative anonymity of any 517 client that is part of it. An inherent feature of being part of this 518 ecosystem is that any client can only remain private relative to the 519 entire space of users using the protocol. Moreover, by owning tokens 520 for a given set of keys, the client's anonymity set shrinks to the 521 total number of clients controlling tokens for the same keys. 523 In the following, we consider the possible ways that servers and 524 servers can leverage their position to try and reduce the anonymity 525 sets that clients belong to (or, user segregation). For each case, 526 we provide mitigations that the Privacy Pass ecosystem must implement 527 to prevent these actions. 529 8.1. Server key rotation 531 Techniques to introduce client "segregation" can be used to reduce 532 client anonymity. Such techniques are closely linked to the type of 533 key schedule that is used by the server. When a server rotates their 534 key, any client that invokes the issuance protocol in this key cycle 535 will be part of a group of possible clients owning valid tokens for 536 this key. To mechanize this attack strategy, a server could 537 introduce a key rotation policy that forces clients into small key 538 cycles. Thus, reducing the size of the anonymity set for these 539 clients. 541 We RECOMMEND that servers should only invoke key rotation for fairly 542 large periods of time such as between 1 and 12 weeks. Key rotations 543 represent a trade-off between client privacy and continued server 544 security. Therefore, it is still important that key rotations occur 545 on a fairly regular cycle to reduce the harmfulness of a server key 546 compromise. 548 With an active user-base, a week gives a fairly large window for 549 clients to participate in the Privacy Pass protocol and thus enjoy 550 the anonymity guarantees of being part of a larger group. The low 551 ceiling of 12 weeks prevents a key compromise from being too 552 destructive. If a server realizes that a key compromise has occurred 553 then the server should sample a new key, and upload the public key to 554 the key registry; invoking any revocation procedures that may apply 555 for the old key. 557 8.2. Large numbers of servers 559 Similarly to the server rotation dynamic that is raised above, if 560 there are a large number of servers then segregation can occur. In 561 the FV, AV and PV running modes (Section 5), a verifier OV can 562 trigger redemptions for any of the available servers. Each 563 redemption token that a client holds essentially corresponds to a bit 564 of information about the client that OV can learn. Therefore, there 565 is an exponential loss in anonymity relative to the number of servers 566 that there are. 568 For example, if there are 32 servers, then OV learns 32 bits of 569 information about the client. If the distribution of server trust is 570 anything close to a uniform distribution, then this is likely to 571 uniquely identify any client amongst all other Internet users. 572 Assuming a uniform distribution is clearly the worst-case scenario, 573 and unlikely to be accurate, but it provides a stark warning against 574 allowing too many servers at any one time. 576 In cases where clients can hold tokens for all servers at any given 577 time, a strict bound SHOULD be applied to the active number of 578 servers in the ecosystem. We propose that allowing no more than 4 579 servers at any one time is highly preferable (leading to a maximum of 580 64 possible user segregations). However, as highlighted in 581 Section 10, having a very large user base (> 5 million users), could 582 potentially allow for larger values. server replacements should only 583 occur with the same frequency as config rotations as they can lead to 584 similar losses in anonymity if clients still hold redemption tokens 585 for previously active servers. 587 In addition, we RECOMMEND that trusted registries indicate at all 588 times which servers are deemed to be active. If a client is asked to 589 invoke any Privacy Pass exchange for an server that is not declared 590 active, then the client SHOULD refuse to retrieve the server 591 configuration during the protocol. 593 8.2.1. Allowing larger number of servers 595 The bounds on the numbers of servers that we proposed above are very 596 restrictive. This is due to the fact that we considered a situation 597 where a client could be issued (and forced to redeem) tokens for any 598 issuing key. 600 An alternative system is to ensure a robust strategy for ensuring 601 that clients only possess redemption tokens for a similarly small 602 number of servers at any one time. This prevents a malicious 603 verifier from being able to invoke redemptions for many servers since 604 the client would only be holding redemption tokens for a small set of 605 servers. When a client is issued tokens from a new server and 606 already has tokens from the maximum number of servers, it simply 607 deletes the oldest set of redemption tokens in storage and then 608 stores the newly acquired tokens. 610 For example, if clients ensure that they only hold redemption tokens 611 for 4 servers, then this increases the potential size of the 612 anonymity sets that the client belongs to. However, this doesn't 613 protect clients completely as it would if only 4 servers were 614 permitted across the whole system. For example, these 4 servers 615 could be different for each client. Therefore, the selection of 616 servers they possess tokens for is still revealing. Understanding 617 this trade-off is important in deciding the effective anonymity of 618 each client in the system. 620 8.3. Partitioning of server key material 622 If there are multiple key registries, or if a key registry colludes 623 with an server, then it is possible to provide a split-view of an 624 server's key material to different clients. This would involve 625 posting different key material in different locations, or actively 626 modifying the key material at a given location. 628 Key registries should operate independently of server's in the 629 ecosystem, and within the guidelines stated in Section 4. Any client 630 should follow the recommendations in Section 7 for determining 631 whether an server and its key material should be trusted. 633 8.4. Tracking and identity leakage 635 Privacy losses may be encountered if too many redemptions are allowed 636 in a short burst. For instance, in the Internet setting, this may 637 allow delegated or asynchronous verifiers to learn more information 638 from the metadata that the client may hold (such as first-party 639 cookies for other domains). Mitigations for this issue are similar 640 to those proposed in Section 8.2 for tackling the problem of having 641 large number of servers. 643 In AV, cached SRRs and their associated server public keys have a 644 similar tracking potential to first party cookies in the browser 645 setting. These considerations will be covered in a separate 646 document, detailing Privacy Pass protocol integration into the wider 647 web architecture [I-D.ietf-privacypass-http-api]. 649 8.5. Client incentives for anonymity reduction 651 Clients may see an incentive in accepting all tokens that are issued 652 by a server, even if the tokens fail later verification checks. This 653 is because tokens effectively represent a form of currency that they 654 can later redeem for some sort of benefit. The verification checks 655 that are put in place are there to ensure that the client does not 656 sacrifice their anonymity. However, a client may judge the 657 "monetary" benefit of owning tokens to be greater than their own 658 privacy. 660 Firstly, a client behaving in this way would not be compliant with 661 the protocol, as laid out in [I-D.ietf-privacypass-protocol]. 663 Secondly, acting in this way only affects the privacy of the 664 immediate client. There is an exception if a large number of clients 665 colluded to accept bad data, then any client that didn't accept would 666 be part of a smaller anonymity set. However, such a situation would 667 be identical to the situation where the total number of clients in 668 the ecosystem is small. Therefore, the reduction in the size of the 669 anonymity set would be equivalent; see Section 8.2 for more details. 671 9. Security considerations 673 We present a number of security considerations that prevent malicious 674 clients from abusing the protocol. 676 9.1. Double-spend protection 678 All issuing server should implement a robust storage-query mechanism 679 for checking that tokens sent by clients have not been spent before. 680 Such tokens only need to be checked for each server individually. 681 But all servers must perform global double-spend checks to avoid 682 clients from exploiting the possibility of spending tokens more than 683 once against distributed token checking systems. For the same 684 reason, the global data storage must have quick update times. While 685 an update is occurring it may be possible for a malicious client to 686 spend a token more than once. 688 9.2. Token exhaustion 690 When a client holds tokens for an server, it is possible for any 691 verifier to invoke that client to redeem tokens for that server. 692 This can lead to an attack where a malicious verifier can force a 693 client to spend all of their tokens for a given server. To prevent 694 this from happening, methods should be put into place to prevent many 695 tokens from being redeemed at once. 697 For example, it may be possible to cache a redemption for the entity 698 that is invoking a token redemption. If the verifier requests more 699 tokens then the client simply returns the cached token that it 700 returned previously. This could also be handled by simply not 701 redeeming any tokens for verification if a redemption had already 702 occurred in a given time window. 704 In AV, the client instead caches the SRR that it received in the 705 asynchronous redemption exchange with the server. If the same 706 verifier attempts another redemption request, then the client simply 707 returns the cached SRR. The SRRs can be revoked by the server, if 708 need be, by providing an expiry date or by signaling that records 709 from a particular window need to be refreshed. 711 9.3. Avoiding server centralization 713 [[OPEN ISSUE: explain potential and mitigations for server 714 centralization]] 716 10. Protocol parametrization 718 We provide a summary of the parameters that we use in the Privacy 719 Pass protocol ecosystem. These parameters are informed by both 720 privacy and security considerations that are highlighted in Section 8 721 and Section 9, respectively. These parameters are intended as a 722 single reference point for those implementing the protocol. 724 Firstly, let U be the total number of users, I be the total number of 725 servers. We let M be the total number of metadata bits that are 726 allowed to be added by any given server. Assuming that each user 727 accept tokens from a uniform sampling of all the possible servers, as 728 a worst-case analysis, this segregates users into a total of 2^I 729 buckets. As such, we see an exponential reduction in the size of the 730 anonymity set for any given user. This allows us to specify the 731 privacy constraints of the protocol below, relative to the setting of 732 A. 734 +------------------------------------------+------------------+ 735 | parameter | value | 736 +==========================================+==================+ 737 | Minimum anonymity set size (A) | 5000 | 738 +------------------------------------------+------------------+ 739 | Recommended key lifetime (L) | 2 - 24 weeks | 740 +------------------------------------------+------------------+ 741 | Recommended key rotation frequency (F) | L/2 | 742 +------------------------------------------+------------------+ 743 | Maximum additional metadata bits (M) | 1 | 744 +------------------------------------------+------------------+ 745 | Maximum allowed servers (I) | (log_2(U/A)-1)/2 | 746 +------------------------------------------+------------------+ 747 | Maximum active issuance keys | 1 | 748 +------------------------------------------+------------------+ 749 | Maximum active redemption keys | 2 | 750 +------------------------------------------+------------------+ 751 | Minimum cryptographic security parameter | 128 bits | 752 +------------------------------------------+------------------+ 754 Table 1 756 10.1. Justification 758 We make the following assumptions in these parameter choices. 760 * Inferring the identity of a user in a 5000-strong anonymity set is 761 difficult. 763 * After 2 weeks, all clients in a system will have rotated to the 764 new key. 766 In terms of additional metadata, the only concrete applications of 767 Privacy Pass that use additional metadata require just a single bit. 768 Therefore, we set the ceiling of permitted metadata to 1 bit for now, 769 this may be revisited in future revisions. 771 The maximum choice of I is based on the equation 1/2 * U/2^(2I) = A. 772 This is derived from the fact that permitting I servers lead to 2^I 773 segregations of the total user-base U. Moreover, if we permit M = 1, 774 then this effectively halves the anonymity set for each server, and 775 thus we incur a factor of 2I in the exponent. By reducing I, we 776 limit the possibility of performing the attacks mentioned in 777 Section 8. 779 We must also account for each user holding issued data for more then 780 one possible active keys. While this may also be a vector for 781 monitoring the access patterns of clients, it is likely to 782 unavoidable that clients hold valid issuance data for the previous 783 key epoch. This also means that the server can continue to verify 784 redemption data for a previously used key. This makes the rotation 785 period much smoother for clients. 787 For privacy reasons, it is recommended that key epochs are chosen 788 that limit clients to holding issuance data for a maximum of two 789 keys. By choosing F = L/2 then the minimum value of F is a week, 790 since the minimum recommended value of L is 2 weeks. Therefore, by 791 the initial assumption, then all users should only have access to 792 only two keys at any given time. This reduces the anonymity set by 793 another half at most. 795 Finally, the minimum security parameter size is related to the 796 cryptographic security offered by the protocol that is run. This 797 parameter corresponds to the number of operations that any adversary 798 has in breaking one of the security guarantees in the Privacy Pass 799 protocol [I-D.ietf-privacypass-protocol]. 801 10.2. Example parameterization 803 Using the specification above, we can give some example 804 parameterizations. For example, the current Privacy Pass browser 805 extension [PPEXT] has nearly 300000 active users (from Chrome and 806 Firefox). As a result, log_2(U/A) is approximately 6 and so the 807 maximum value of I should be 3. 809 If the value of U is much bigger (e.g. 5 million) then this would 810 permit I = (log_2(5000000/5000)-1)/2 ~= 4 servers. 812 10.3. Allowing more servers 814 Using the recommendations in Section 8.2.1, it is possible to 815 tolerate larger number of servers if clients in the ecosystem ensure 816 that they only store tokens for a small number of them. In 817 particular, if clients limit their storage of redemption tokens to 818 the bound implied by I, then prevents a malicious verifier from 819 triggering redemptions for all servers in the ecosystem. 821 11. Extension integration policy 823 The Privacy Pass protocol and ecosystem are both intended to be 824 receptive to extensions that expand the current set of functionality. 825 As specified in [I-D.ietf-privacypass-protocol], all extensions to 826 the Privacy Pass protocol SHOULD be specified as separate documents 827 that modify the content of this document in some way. We provide 828 guidance on the type of modifications that are possible in the 829 following. 831 Any such extension should also come with a detailed analysis of the 832 privacy impacts of the extension, why these impacts are justified, 833 and guidelines on changes to the parametrization in Section 10. 834 Similarly, extensions MAY also add new server running modes, if 835 applicable, to those that are documented in Section 5. 837 Any extension to the Privacy Pass protocol must adhere to the 838 guidelines specified in Section 4 for managing server public key 839 data. 841 12. Existing applications 843 The following is a non-exhaustive list of applications that currently 844 make use of the Privacy Pass protocol, or some variant of the 845 underlying functionality. 847 12.1. Cloudflare challenge pages 849 Cloudflare uses an implementation of the Privacy Pass protocol for 850 allowing clients that have previously interacted with their Internet 851 challenge protection system to bypass future challenges [PPSRV]. 852 These challenges can be expensive for clients, and there have been 853 cases where bugs in the implementations can severely degrade client 854 accessibility. 856 Clients must install a browser extension [PPEXT] that acts as the 857 Privacy Pass client in an exchange with Cloudflare's Privacy Pass 858 server, when an initial challenge solution is provided. The client 859 extension stores the issued tokens and presents a valid redemption 860 token when it sees future Cloudflare challenges. If the redemption 861 token is verified by the server, the client passes through the 862 security mechanism without completing a challenge. 864 12.2. Trust Token API 866 The Trust Token API [TrustTokenAPI] has been devised as a generic API 867 for providing Privacy Pass functionality in the browser setting. The 868 API is intended to be implemented directly into browsers so that 869 server's can directly trigger the Privacy Pass workflow. 871 12.3. Zero-knowledge Access Passes 873 The PrivateStorage API developed by Least Authority is a solution for 874 uploading and storing end-to-end encrypted data in the cloud. A 875 recent addition to the API [PrivateStorage] allows clients to 876 generate Zero-knowledge Access Passes (ZKAPs) that the client can use 877 to show that it has paid for the storage space that it is using. The 878 ZKAP protocol is based heavily on the Privacy Pass redemption 879 mechanism. The client receives ZKAPs when it pays for storage space, 880 and redeems the passes when it interacts with the PrivateStorage API. 882 12.4. Basic Attention Tokens 884 The browser Brave uses Basic Attention Tokens (BATs) to provide the 885 basis for an anonymity-preserving rewards scheme [Brave]. The BATs 886 are essentially Privacy Pass redemption tokens that are provided by a 887 central Brave server when a client performs some action that triggers 888 a reward event (such as watching an advertisement). When the client 889 amasses BATs, it can redeem them with the Brave central server for 890 rewards. 892 12.5. Token Based Services 894 Similarly to BATs, a more generic approach for providing anonymous 895 peers to purchase resources from anonymous servers has been proposed 896 [OpenPrivacy]. The protocol is based on a variant of Privacy Pass 897 and is intended to allow clients purchase (or pre-purchase) services 898 such as message hosting, by using Privacy Pass redemption tokens as a 899 form of currency. This is also similar to how ZKAPs are used. 901 13. References 903 13.1. Normative References 905 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 906 Requirement Levels", BCP 14, RFC 2119, 907 DOI 10.17487/RFC2119, March 1997, 908 . 910 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 911 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 912 . 914 13.2. Informative References 916 [Brave] "Brave Rewards", n.d., . 918 [HIJK21] Huang, S., Iyengar, S., Jeyaraman, S., Kushwah, S., Lee, 919 C.K., Luo, Z., Mohassel, P., Raghunathan, A., Shaikh, S., 920 Sung, Y.C., and A. Zhang, "PrivateStats: De-Identified 921 Authenticated Logging at Scale", January 2021, 922 . 926 [I-D.ietf-privacypass-http-api] 927 Valdez, S., "Privacy Pass HTTP API", Work in Progress, 928 Internet-Draft, draft-ietf-privacypass-http-api-00, 5 929 January 2021, . 932 [I-D.ietf-privacypass-protocol] 933 Celi, S., Davidson, A., and A. Faz-Hernandez, "Privacy 934 Pass Protocol Specification", Work in Progress, Internet- 935 Draft, draft-ietf-privacypass-protocol-00, 5 January 2021, 936 . 939 [KLOR20] Kreuter, B., Lepoint, T., Orrù, M., and M. Raykova, 940 "Anonymous Tokens with Private Metadata Bit", 941 DOI 10.1007/978-3-030-56784-2_11, Advances in Cryptology - 942 CRYPTO 2020 pp. 308-336, 2020, 943 . 945 [OpenPrivacy] 946 "Token Based Services - Differences from PrivacyPass", 947 n.d., . 950 [PPEXT] "Privacy Pass Browser Extension", n.d., 951 . 954 [PPSRV] Sullivan, N., "Cloudflare Supports Privacy Pass", n.d., 955 . 958 [PrivateStorage] 959 Steininger, L., "The Path from S4 to PrivateStorage", 960 n.d., . 963 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 964 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 965 . 967 [TrustTokenAPI] 968 Google, ., "Getting started with Trust Tokens", n.d., 969 . 971 Appendix A. Contributors 973 * Alex Davidson (alex.davidson92@gmail.com) 975 * Christopher Wood (caw@heapingbits.net) 977 Authors' Addresses 979 Alex Davidson 980 LIP 981 Lisbon 982 Portugal 984 Email: alex.davidson92@gmail.com 986 Christopher A. Wood 987 Cloudflare 988 101 Townsend St 989 San Francisco, 990 United States of America 992 Email: caw@heapingbits.net