idnits 2.17.1 draft-davidson-pp-protocol-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 1355 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-21) exists of draft-irtf-cfrg-voprf-03 -- Obsolete informational reference (is this intentional?): RFC 7049 (Obsoleted by RFC 8949) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Davidson 3 Internet-Draft Cloudflare 4 Intended status: Informational 13 July 2020 5 Expires: 14 January 2021 7 Privacy Pass: The Protocol 8 draft-davidson-pp-protocol-01 10 Abstract 12 This document specifies the Privacy Pass protocol. This protocol 13 provides anonymity-preserving authorization of clients to servers. 14 In particular, client re-authorization events cannot be linked to any 15 previous initial authorization. Privacy Pass is intended to be used 16 as a performant protocol in the application-layer. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Motivating use-cases . . . . . . . . . . . . . . . . . . 4 55 3.2. Anonymity and security guarantees . . . . . . . . . . . . 5 56 3.3. Basic assumptions . . . . . . . . . . . . . . . . . . . . 5 57 4. Protocol description . . . . . . . . . . . . . . . . . . . . 5 58 4.1. Server setup . . . . . . . . . . . . . . . . . . . . . . 6 59 4.2. Client setup . . . . . . . . . . . . . . . . . . . . . . 6 60 4.3. Issuance phase . . . . . . . . . . . . . . . . . . . . . 6 61 4.4. Redemption phase . . . . . . . . . . . . . . . . . . . . 6 62 4.4.1. Client info . . . . . . . . . . . . . . . . . . . . . 7 63 4.4.2. Double-spend protection . . . . . . . . . . . . . . . 7 64 4.5. Handling errors . . . . . . . . . . . . . . . . . . . . . 7 65 5. Functionality . . . . . . . . . . . . . . . . . . . . . . . . 8 66 5.1. Data structures . . . . . . . . . . . . . . . . . . . . . 8 67 5.1.1. Ciphersuite . . . . . . . . . . . . . . . . . . . . . 8 68 5.1.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.1.3. IssuanceInput . . . . . . . . . . . . . . . . . . . . 8 70 5.1.4. IssuanceResponse . . . . . . . . . . . . . . . . . . 9 71 5.1.5. RedemptionToken . . . . . . . . . . . . . . . . . . . 9 72 5.1.6. RedemptionRequest . . . . . . . . . . . . . . . . . . 9 73 5.1.7. RedemptionResponse . . . . . . . . . . . . . . . . . 10 74 5.2. API functions . . . . . . . . . . . . . . . . . . . . . . 10 75 5.2.1. Generate . . . . . . . . . . . . . . . . . . . . . . 10 76 5.2.2. Issue . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.2.3. Process . . . . . . . . . . . . . . . . . . . . . . . 11 78 5.2.4. Redeem . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.2.5. Verify . . . . . . . . . . . . . . . . . . . . . . . 11 80 5.3. Error types . . . . . . . . . . . . . . . . . . . . . . . 12 81 6. Security considerations . . . . . . . . . . . . . . . . . . . 12 82 6.1. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 12 83 6.2. One-more unforgeability . . . . . . . . . . . . . . . . . 13 84 6.3. Double-spend protection . . . . . . . . . . . . . . . . . 14 85 6.4. Additional token metadata . . . . . . . . . . . . . . . . 14 86 6.5. Maximum number of tokens issued . . . . . . . . . . . . . 14 87 7. VOPRF instantiation . . . . . . . . . . . . . . . . . . . . . 14 88 7.1. Recommended ciphersuites . . . . . . . . . . . . . . . . 15 89 7.2. Protocol contexts . . . . . . . . . . . . . . . . . . . . 15 90 7.3. Functionality . . . . . . . . . . . . . . . . . . . . . . 15 91 7.3.1. Generate . . . . . . . . . . . . . . . . . . . . . . 15 92 7.3.2. Issue . . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.3.3. Process . . . . . . . . . . . . . . . . . . . . . . . 16 94 7.3.4. Redeem . . . . . . . . . . . . . . . . . . . . . . . 16 95 7.3.5. Verify . . . . . . . . . . . . . . . . . . . . . . . 17 96 7.4. Security justification . . . . . . . . . . . . . . . . . 17 98 8. Protocol ciphersuites . . . . . . . . . . . . . . . . . . . . 17 99 8.1. PP(OPRF2) . . . . . . . . . . . . . . . . . . . . . . . . 18 100 8.2. PP(OPRF4) . . . . . . . . . . . . . . . . . . . . . . . . 18 101 8.3. PP(OPRF5) . . . . . . . . . . . . . . . . . . . . . . . . 18 102 9. Extensions framework policy . . . . . . . . . . . . . . . . . 18 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 105 10.2. Informative References . . . . . . . . . . . . . . . . . 19 106 Appendix A. Document contributors . . . . . . . . . . . . . . . 20 107 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 109 1. Introduction 111 A common problem on the Internet is providing an effective mechanism 112 for servers to derive trust from clients that they interact with. 113 Typically, this can be done by providing some sort of authorization 114 challenge to the client. But this also negatively impacts the 115 experience of clients that regularly have to solve such challenges. 117 To mitigate accessibility issues, a client that correctly solves the 118 challenge can be provided with a cookie. This cookie can be 119 presented the next time the client interacts with the server, instead 120 of performing the challenge. However, this does not solve the 121 problem of reauthorization of clients across multiple domains. Using 122 current tools, providing some multi-domain authorization token would 123 allow linking client browsing patterns across those domains, and 124 severely reduces their online privacy. 126 The Privacy Pass protocol provides a set of cross-domain 127 authorization tokens that protect the client's anonymity in message 128 exchanges with a server. This allows clients to communicate an 129 attestation of a previously authenticated server action, without 130 having to reauthenticate manually. The tokens retain anonymity in 131 the sense that the act of revealing them cannot be linked back to the 132 session where they were initially issued. 134 This document lays out the generic description of the protocol, along 135 with the data and message formats. We detail an implementation of 136 the protocol functionality based on the description of a verifiable 137 oblivious pseudorandom function [I-D.irtf-cfrg-voprf]. 139 This document DOES NOT cover the architectural framework required for 140 running and maintaining the Privacy Pass protocol in the Internet 141 setting. In addition, it DOES NOT cover the choices that are 142 necessary for ensuring that client privacy leaks do not occur. Both 143 of these considerations are covered in a separate document 144 [draft-davidson-pp-architecture]. In addition, 146 [draft-svaldez-pp-http-api] provides an instantiation of this 147 protocol intended for the HTTP setting. 149 2. Terminology 151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 153 document are to be interpreted as described in [RFC2119]. 155 The following terms are used throughout this document. 157 * Server: A service that provides the server-side functionality 158 required by the protocol. May be referred to as the issuer. 160 * Client: An entity that seeks authorization from a server that 161 supports interactions in the Privacy Pass protocol. 163 * Key: The secret key used by the server for authorizing client 164 data. 166 We assume that all protocol messages are encoded into raw byte format 167 before being sent. We use the TLS presentation language [RFC8446] to 168 describe the structure of protocol data types and messages. 170 3. Background 172 We discuss the core motivation behind the protocol along with the 173 guarantees and assumptions that we make in this document. 175 3.1. Motivating use-cases 177 The Privacy Pass protocol was originally developed to provide 178 anonymous authorization of Tor users. In particular, the protocol 179 allows clients to reveal authorization tokens that they have been 180 issued without linking the authorization to the actual issuance 181 event. This means that the tokens cannot be used to link the 182 browsing patterns of clients that reveal tokens. 184 Beyond these uses-cases, the Privacy Pass protocol is used in a 185 number of practical applications. See [DGSTV18], [TrustTokenAPI], 186 [PrivateStorage], [OpenPrivacy], and [Brave] for examples. 188 3.2. Anonymity and security guarantees 190 Privacy Pass provides anonymity-preserving authorization tokens for 191 clients. Throughout this document, we use the terms "anonymous", 192 "anonymous-preserving" and "anonymity" to refer to the core security 193 guarantee of the protocol. Informally, this guarantee means that any 194 token issued by a server key and subsequently redeemed is 195 indistinguishable from any other token issued under the same key. 197 Privacy Pass also prohibits clients from forging tokens, as otherwise 198 the protocol would have little value as an authorization protocol. 199 Informally, this means any client that is issued "N" tokens under a 200 given server key cannot redeem more than "N" valid tokens. 202 Section 6 elaborates on these protocol anonymity and security 203 requirements. 205 3.3. Basic assumptions 207 We make only a few minimal assumptions about the environment of the 208 clients and servers supporting the Privacy Pass protocol. 210 * At any one time, we assume that the server uses only one 211 configuration containing their ciphersuite choice along with their 212 secret key data. This ensures that all clients are issued tokens 213 under the single key associated with any given epoch. 215 * We assume that the client has access to a global directory of the 216 current public parts of the configurations used the server. 218 The wider ecosystem that this protocol is employed in is described in 219 [draft-davidson-pp-architecture]. 221 4. Protocol description 223 The Privacy Pass protocol is split into two phases that are built 224 upon the functionality described in Section 5 later. 226 The first phase, "issuance", provides the client with unlinkable 227 tokens that can be used to initiate re-authorization with the server 228 in the future. The second phase, "redemption", allows the client to 229 redeem a given re-authorization token with the server that it 230 interacted with during the issuance phase. The protocol must satisfy 231 two cryptographic security requirements known as "unlinkability" and 232 "unforgeability". These requirements are covered in Section 6. 234 4.1. Server setup 236 Before the protocol takes place, the server chooses a ciphersuite and 237 generates a keypair by running "(pkS, skS) = KeyGen()". This 238 configuration must be available to all clients that interact with the 239 server (for the purpose of engaging in a Privacy Pass exchange). We 240 assume that the server has a public (and unique) identity that the 241 client uses to retrieve this configuration. 243 4.2. Client setup 245 The client initialises a global storage system "store" that allows it 246 store the tokens that are received during issuance. The storage 247 system is a map of server identifiers ("server.id") to arrays of 248 stored tokens. We assume that the client knows the server public key 249 "pkS" ahead of time. The client picks a value "m" of tokens to 250 receive during the issuance phase. In 251 [draft-davidson-pp-architecture] we discuss mechanisms that the 252 client can use to ensure that this public key is consistent across 253 the entire ecosystem. 255 4.3. Issuance phase 257 The issuance phase allows the client to receive "m" anonymous 258 authorization tokens from the server. 260 Client(pkS, m) Server(skS, pkS) 261 ------------------------------------------------------------ 262 cInput = Generate(m) 263 req = cInput.req 265 req 266 -------------------> 268 serverResp = Issue(pkS, skS, req) 270 issueResp 271 <------------------- 273 tokens = Process(pkS, cInput, issueResp) 274 store[server.id].push(tokens) 276 4.4. Redemption phase 278 The redemption phase allows the client to anonymously reauthenticate 279 to the server, using data that it has received from a previous 280 issuance phase. 282 Client(info) Server(skS, pkS) 283 ------------------------------------------------------------ 284 token = store[Issue.id].pop() 285 req = Redeem(token, info) 287 req 288 ------------------> 290 if (dsIdx.includes(req.data)) { 291 raise ERR_DOUBLE_SPEND 292 } 293 resp = Verify(pkS, skS, req) 294 if (resp.success) { 295 dsIdx.push(req.data) 296 } 298 resp 299 <------------------ 300 Output resp 302 4.4.1. Client info 304 The client input "info" is arbitrary byte data that is used for 305 linking the redemption request to the specific session. We RECOMMEND 306 that "info" is constructed as the following concatenated byte-encoded 307 data: 309 len(aux) || aux || len(server.id) || server.id || current_time() 311 where "len(x)" is the length of "x" in bytes, and "aux" is arbitrary 312 auxiliary data chosen by the client. The usage of "current_time()" 313 allows the server to check that the redemption request has happened 314 in an appropriate time window. 316 4.4.2. Double-spend protection 318 To protect against clients that attempt to spend a value "req.data" 319 more than once, the server uses an index, "dsIdx", to collect valid 320 inputs it witnesses. Since this store needs to only be optimized for 321 storage and querying, a structure such as a Bloom filter suffices. 322 The storage should be parameterized to live as long as the server 323 keypair that is in use. See {{sec-reqs} for more details. 325 4.5. Handling errors 327 It is possible for the API functions from Section 5.2 to return one 328 of the errors indicated in Section 5.3 rather than their expected 329 value. In these cases, we assume that the entire protocol aborts. 331 5. Functionality 333 This section details the data types and API functions that are used 334 to construct the protocol in Section 4. 336 We provide an explicit instantiation of the Privacy Pass API in 337 Section 7.3, based on the public API provided in 338 [I-D.irtf-cfrg-voprf]. 340 5.1. Data structures 342 The following data structures are used throughout the Privacy Pass 343 protocol and are written in the TLS presentation language [RFC8446]. 344 It is intended that any of these data structures can be written into 345 widely-adopted encoding schemes such as those detailed in TLS 346 [RFC8446], CBOR [RFC7049], and JSON [RFC7159]. 348 5.1.1. Ciphersuite 350 The "Ciphersuite" enum provides identifiers for each of the supported 351 ciphersuites of the protocol. Some initial values that are supported 352 by the core protocol are described in Section 8. Note that the list 353 of supported ciphersuites may be expanded by extensions to the core 354 protocol description in separate documents. 356 5.1.2. Keys 358 We use the following types to describe the public and private keys 359 used by the server. 361 opaque PublicKey<1..2^16-1> 362 opaque PrivateKey<1..2^16-1> 364 5.1.3. IssuanceInput 366 The "IssuanceInput" struct describes the data that is initially 367 generated by the client during the issuance phase. 369 Firstly, we define sequences of bytes that partition the client 370 input. 372 opaque Internal<1..2^16-1> 373 opaque IssuanceRequest<1..2^16-1> 375 These data types represent members of the wider "IssuanceInput" data 376 type. 378 struct { 379 Internal data[m] 380 IssuanceRequest req[m] 381 } IssuanceInput; 383 Note that a "IssuanceInput" contains equal-length arrays of 384 "Internal" and "IssuanceRequest" types corresponding to the number of 385 tokens that should be issued. 387 5.1.4. IssuanceResponse 389 Firstly, the "IssuedToken" type corresponds to a single sequence of 390 bytes that represents a single issued token received from the server. 392 opaque IssuedToken<1..2^16-1> 394 Then an "IssuanceResponse" corresponds to a collection of 395 "IssuedTokens" as well as a sequence of bytes "proof". 397 struct { 398 IssuedToken tokens[m] 399 opaque proof<1..2^16-1> 400 } 402 The value of "m" is equal to the length of the "IssuanceRequest" 403 vector sent by the client. 405 5.1.5. RedemptionToken 407 The "RedemptionToken" struct contains the data required to generate 408 the client message in the redemption phase of the Privacy Pass 409 protocol. 411 struct { 412 opaque data<1..2^16-1>; 413 opaque issued<1..2^16-1>; 414 } RedemptionToken; 416 5.1.6. RedemptionRequest 418 The "RedemptionRequest" struct consists of the data that is sent by 419 the client during the redemption phase of the protocol. 421 struct { 422 opaque data<1..2^16-1>; 423 opaque tag<1..2^16-1>; 424 opaque info<1..2^16-1>; 425 } RedemptionRequest; 427 5.1.7. RedemptionResponse 429 The "RedemptionResponse" struct corresponds to a boolean value that 430 indicates whether the "RedemptionRequest" sent by the client is 431 valid. It can also contain any associated data. 433 struct { 434 boolean success; 435 opaque ad<1..2^16-1>; 436 } RedemptionResponse; 438 5.2. API functions 440 The following functions wrap the core of the functionality required 441 in the Privacy Pass protocol. For each of the descriptions, we 442 essentially provide the function signature, leaving the actual 443 contents to be defined by specific instantiations or extensions of 444 the protocol. 446 5.2.1. Generate 448 A function run by the client to generate the initial data that is 449 used as its input in the Privacy Pass protocol. 451 Inputs: 453 * "m": A "uint8" value corresponding to the number of Privacy Pass 454 tokens to generate. 456 Outputs: 458 * "input": An "IssuanceInput" struct. 460 5.2.2. Issue 462 A function run by the server to issue valid redemption tokens to the 463 client. 465 Inputs: 467 * "pkS": A server "PublicKey". 469 * "skS": A server "PrivateKey". 471 * "req": An "IssuanceRequest" struct. 473 Outputs: 475 * "resp": An "IssuanceResponse" struct. 477 5.2.3. Process 479 Run by the client when processing the server response in the issuance 480 phase of the protocol. 482 Inputs: 484 * "pkS": An server "PublicKey". 486 * "input": An "IssuanceInput" struct. 488 * "resp": An "IssuanceResponse" struct. 490 Outputs: 492 * "tokens": A vector of "RedemptionToken" structs, whose length is 493 equal to length of the internal "ServerEvaluation" vector in the 494 "IssuanceResponse" struct. 496 Throws: 498 * "ERR_PROOF_VALIDATION" (Section 5.3) 500 5.2.4. Redeem 502 Run by the client in the redemption phase of the protocol to generate 503 the client's message. 505 Inputs: 507 * "token": A "RedemptionToken" struct. 509 * "info": An "opaque<1..2^16-1>" type corresponding to data that is 510 linked to the redemption. See Section 4.4.1 for advice on how to 511 construct this. 513 Outputs: 515 * "req": A "RedemptionRequest" struct. 517 5.2.5. Verify 519 Run by the server in the redemption phase of the protocol. 520 Determines whether the data sent by the client is valid. 522 Inputs: 524 * "pkS": An server "PublicKey". 526 * "skS": An server "PrivateKey". 528 * "req": A "RedemptionRequest" struct. 530 Outputs: 532 * "resp": A "RedemptionResponse" struct. 534 5.3. Error types 536 * "ERR_PROOF_VALIDATION": Error occurred when a client attempted to 537 verify the proof that is part of the server's response. 539 * "ERR_DOUBLE_SPEND": Error occurred when a client has attempted to 540 redeem a token that has already been used for authorization. 542 6. Security considerations 544 We discuss the security requirements that are necessary to uphold 545 when instantiating the Privacy Pass protocol. In particular, we 546 focus on the security requirements of "unlinkability", and 547 "unforgeability". Informally, the notion of unlinkability is 548 required to preserve the anonymity of the client in the redemption 549 phase of the protocol. The notion of unforgeability is to protect 550 against an adversarial client that may look to subvert the security 551 of the protocol. 553 Both requirements are modelled as typical cryptographic security 554 games, following the formats laid out in [DGSTV18] and [KLOR20]. 556 Note that the privacy requirements of the protocol are covered in the 557 architectural framework document [draft-davidson-pp-architecture]. 559 6.1. Unlinkability 561 Formally speaking the security model is the following: 563 * The adversary runs the server setup and generates a keypair "(pkS, 564 skS)". 566 * The adversary specifies a number "Q" of issuance phases to 567 initiate, where each phase "i in range(Q)" consists of "m_i" Issue 568 evaluations. 570 * The adversary runs "Issue" using the keypair that it generated on 571 each of the client messages in the issuance phase. 573 * When the adversary wants, it stops the issuance phase, and a 574 random number "l" is picked from "range(Q)". 576 * A redemption phase is initiated with a single token with index "i" 577 randomly sampled from "range(m_l)". 579 * The adversary guesses an index "l_guess" corresponding to the 580 index of the issuance phase that it believes the redemption token 581 was received in. 583 * The adversary succeeds if "l == l_guess". 585 The security requirement is that the adversary has only a negligible 586 probability of success greater than "1/Q". 588 6.2. One-more unforgeability 590 The one-more unforgeability requirement states that it is hard for 591 any adversarial client that has received "m" valid tokens from the 592 issuance phase to redeem "m+1" of them. In essence, this requirement 593 prevents a malicious client from being able to forge valid tokens 594 based on the Issue responses that it sees. 596 The security model roughly takes the following form: 598 * The adversary specifies a number "Q" of issuance phases to 599 initiate with the server, where each phase "i in range(Q)" 600 consists of "m_i" server evaluation. Let "m = sum(m_i)" where "i 601 in range(Q)". 603 * The adversary receives "Q" responses, where the response with 604 index "i" contains "m_i" individual tokens. 606 * The adversary initiates "m_adv" redemption sessions with the 607 server and the server verifies that the sessions are successful 608 (return true), and that each request includes a unique token. The 609 adversary succeeds in "m_succ =< m_adv" redemption sessions. 611 * The adversary succeeds if "m_succ > m". 613 The security requirement is that the adversarial client has only a 614 negligible probability of succeeding. 616 Note that [KLOR20] strengthens the capabilities of the adversary, in 617 comparison to the original work of [DGSTV18]. In [KLOR20], the 618 adversary is provided with oracle access that allows it to verify 619 that the server responses in the issuance phase are valid. 621 6.3. Double-spend protection 623 All issuing servers should implement a robust, global storage-query 624 mechanism for checking that tokens sent by clients have not been 625 spent before. Such tokens only need to be checked for each server 626 individually. This prevents clients from "replaying" previous 627 requests, and is necessary for achieving the unforgeability 628 requirement. 630 6.4. Additional token metadata 632 Some use-cases of the Privacy Pass protocol benefit from associating 633 a limited amount of metadata with tokens that can be read by the 634 server when a token is redeemed. Adding metadata to tokens can be 635 used as a vector to segment the anonymity of the client in the 636 protocol. Therefore, it is important that any metadata that is added 637 is heavily limited. 639 Any additional metadata that can be added to redemption tokens should 640 be described in the specific protocol instantiation. Note that any 641 additional metadata will have to be justified in light of the privacy 642 concerns raised above. For more details on the impacts associated 643 with segmenting user privacy, see [draft-davidson-pp-architecture]. 645 Any metadata added to tokens will be considered either "public" or 646 "private". Public metadata corresponds to unmodifiable bits that a 647 client can read. Private metadata corresponds to unmodifiable 648 private bits that should be obscured to the client. 650 Note that the instantiation in Section 7 provides randomized 651 redemption tokens with no additional metadata for an server with a 652 single key. 654 6.5. Maximum number of tokens issued 656 Servers SHOULD impose a hard ceiling on the number of tokens that can 657 be issued in a single issuance phase to a client. If there is no 658 limit, malicious clients could abuse this and cause excessive 659 computation, leading to a Denial-of-Service attack. 661 7. VOPRF instantiation 663 In this section, we show how to instantiate the functional API in 664 Section 5 with the VOPRF protocol described in [I-D.irtf-cfrg-voprf]. 665 Moreover, we show that this protocol satisfies the security 666 requirements laid out in Section 6, based on the security proofs 667 provided in [DGSTV18] and [KLOR20]. 669 7.1. Recommended ciphersuites 671 The RECOMMENDED server ciphersuites are as follows: detailed in 672 [I-D.irtf-cfrg-voprf]: 674 * OPRF(curve448, SHA-512) (ID = 0x0002); 676 * OPRF(P-384, SHA-512) (ID = 0x0004); 678 * OPRF(P-521, SHA-512) (ID = 0x0005). 680 We deliberately avoid the usage of smaller ciphersuites (associated 681 with P-256 and curve25519) due to the potential to reduce security to 682 unfavourable levels via static Diffie Hellman attacks. See 683 [I-D.irtf-cfrg-voprf] for more details. 685 7.2. Protocol contexts 687 Note that we must run the verifiable version of the protocol in 688 [I-D.irtf-cfrg-voprf]. Therefore the "server" takes the role of the 689 "Server" running in "modeVerifiable". In other words, the "server" 690 runs "(ctxtI, pkS) = SetupVerifiableServer(suite)"; where "suite" is 691 one of the ciphersuites in Section 7.1, "ctxt" contains the internal 692 VOPRF server functionality and secret key "skS", and "pkS" is the 693 server public key. Likewise, run "ctxtC = 694 SetupVerifiableClient(suite)" to generate the Client context. 696 7.3. Functionality 698 We instantiate each functions using the API functions in 699 [I-D.irtf-cfrg-voprf]. Note that we use the framework mentioned in 700 the document to allow for batching multiple tokens into a single 701 VOPRF evaluation. For the explicit signatures of each of the 702 functions, refer to Section 5. 704 7.3.1. Generate 705 def Generate(m): 706 tokens = [] 707 blindedTokens = [] 708 for i in range(m): 709 x = random_bytes() 710 (token, blindedToken) = Blind(x) 711 token[i] = token 712 blindedToken[i] = blindedToken 713 return IssuanceInput { 714 internal: tokens, 715 req: blindedTokens, 716 } 718 7.3.2. Issue 720 For this functionality, note that we supply multiple tokens in "req" 721 to "Evaluate". This allows batching a single proof object for 722 multiple evaluations. While the construction in 723 [I-D.irtf-cfrg-voprf] only permits a single input, we follow the 724 advice for providing vectors of inputs. 726 def Issue(pkS, skS, req): 727 Ev = Evaluate(skS, pkS, req) 728 return IssuanceResponse { 729 tokens: Ev.elements, 730 proof: Ev.proof, 731 } 733 7.3.3. Process 735 Similarly to "Issue", we follow the advice for providing vectors of 736 inputs to the "Unblind" function for verifying the batched proof 737 object. 739 Process(pkS, input, resp): 740 unblindedTokens = Unblind(pkS, input.data, input.req, resp) 741 redemptionTokens = [] 742 for bt in unblindedTokens: 743 rt = RedemptionToken { data: input.data, issued: bt } 744 redemptionTokens[i] = rt 745 return redemptionTokens 747 7.3.4. Redeem 748 def Redeem(token, info): 749 tag = Finalize(token.data, token.issued, info) 750 return RedemptionRequest { 751 data: data, 752 tag: tag, 753 info: info, 754 } 756 7.3.5. Verify 758 def Verify(pkS, skS, req): 759 resp = VerifyFinalize(skS, pkS, req.data, req.info, req.tag) 760 Output RedemptionResponse { 761 success: resp 762 } 764 7.4. Security justification 766 The protocol devised in Section 4, coupled with the API instantiation 767 in Section 7.3, are equivalent to the protocol description in 768 [DGSTV18] and [KLOR20] from a security perspective. In [DGSTV18], it 769 is proven that this protocol satisfies the security requirements of 770 unlinkability (Section 6.1) and unforgeability (Section 6.2). 772 The unlinkability property follows unconditionally as the view of the 773 adversary in the redemption phase is distributed independently of the 774 issuance phase. The unforgeability property follows from the one- 775 more decryption security of the ElGamal cryptosystem [DGSTV18]. In 776 [KLOR20] it is also proven that this protocol satisfies the stronger 777 notion of unforgeability, where the adversary is granted a 778 verification oracle, under the chosen-target Diffie-Hellman 779 assumption. 781 Note that the existing security proofs do not leverage the VOPRF 782 primitive as a black-box in the security reductions. Instead, it 783 relies on the underlying operations in a non-black-box manner. 784 Hence, an explicit reduction from the generic VOPRF primitive to the 785 Privacy Pass protocol would strengthen these security guarantees. 787 8. Protocol ciphersuites 789 The ciphersuites that we describe for the Privacy Pass protocol are 790 derived from the core instantiations of the protocol (such as in 791 Section 7). 793 In each of the ciphersuites below, the maximum security provided 794 corresponds to the maximum difficulty of computing a discrete 795 logarithm in the group. Note that the actual security level MAY be 796 lower. See the security considerations in [I-D.irtf-cfrg-voprf] for 797 examples. 799 8.1. PP(OPRF2) 801 * OPRF2 = OPRF(curve448, SHA-512) 803 * ID = 0x0001 805 * Maximum security provided: 224 bits 807 8.2. PP(OPRF4) 809 * OPRF4 = OPRF(P-384, SHA-512) 811 * ID = 0x0002 813 * Maximum security provided: 192 bits 815 8.3. PP(OPRF5) 817 * OPRF5 = OPRF(P-521, SHA-512) 819 * ID = 0x0003 821 * Maximum security provided: 256 bits 823 9. Extensions framework policy 825 The intention with providing the Privacy Pass API in Section 5 is to 826 allow new instantiations of the Privacy Pass protocol. These 827 instantiations may provide either modified VOPRF constructions, or 828 simply implement the API in a completely different way. 830 Extensions to this initial draft SHOULD be specified as separate 831 documents taking one of two possible routes: 833 * Produce new VOPRF-like primitives that use the same public API 834 provided in [I-D.irtf-cfrg-voprf] to implement the Privacy Pass 835 API, but with different internal operations. 837 * Implement the Privacy Pass API in a different way to the proposed 838 implementation in Section 7. 840 If an extension requires changing the generic protocol description as 841 described in Section 4, then the change may have to result in changes 842 to the draft specification here also. 844 Each new extension that modifies the internals of the protocol in 845 either of the two ways MUST re-justify that the extended protocol 846 still satisfies the security requirements in Section 6. Protocol 847 extensions MAY put forward new security guarantees if they are 848 applicable. 850 The extensions MUST also conform with the extension framework policy 851 as set out in the architectural framework document. For example, 852 this may concern any potential impact on client anonymity that the 853 extension may introduce. 855 10. References 857 10.1. Normative References 859 [draft-davidson-pp-architecture] 860 Davidson, A., "Privacy Pass: Architectural Framework", 861 n.d., . 864 [draft-svaldez-pp-http-api] 865 Valdez, S., "Privacy Pass: HTTP API", n.d., 866 . 869 [I-D.irtf-cfrg-voprf] 870 Davidson, A., Sullivan, N., and C. Wood, "Oblivious 871 Pseudorandom Functions (OPRFs) using Prime-Order Groups", 872 Work in Progress, Internet-Draft, draft-irtf-cfrg-voprf- 873 03, 9 March 2020, . 876 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 877 Requirement Levels", BCP 14, RFC 2119, 878 DOI 10.17487/RFC2119, March 1997, 879 . 881 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 882 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 883 . 885 10.2. Informative References 887 [Brave] "Brave Rewards", n.d., . 889 [DGSTV18] "Privacy Pass, Bypassing Internet Challenges Anonymously", 890 n.d., . 893 [KLOR20] "Anonymous Tokens with Private Metadata Bit", n.d., 894 . 896 [OpenPrivacy] 897 "Token Based Services - Differences from PrivacyPass", 898 n.d., . 901 [PrivateStorage] 902 Steininger, L., "The Path from S4 to PrivateStorage", 903 n.d., . 906 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 907 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 908 October 2013, . 910 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 911 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 912 2014, . 914 [TrustTokenAPI] 915 WICG, ., "Trust Token API", n.d., 916 . 918 Appendix A. Document contributors 920 * Alex Davidson (alex.davidson92@gmail.com) 922 * Sofia Celi (cherenkov@riseup.net) 924 * Christopher Wood (caw@heapingbits.net) 926 Author's Address 928 Alex Davidson 929 Cloudflare 930 Lisbon 931 Portugal 933 Email: alex.davidson92@gmail.com