idnits 2.17.1 draft-ietf-privacypass-protocol-00.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. == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 958 lines 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 (5 January 2021) is 1207 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-05 -- 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 (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Celi 3 Internet-Draft Cloudflare 4 Intended status: Informational A. Davidson 5 Expires: 9 July 2021 LIP 6 A. Faz-Hernandez 7 Cloudflare 8 5 January 2021 10 Privacy Pass Protocol Specification 11 draft-ietf-privacypass-protocol-00 13 Abstract 15 This document specifies the Privacy Pass protocol. This protocol 16 provides anonymity-preserving authorization of clients to servers. 17 In particular, client re-authorization events cannot be linked to any 18 previous initial authorization. Privacy Pass is intended to be used 19 as a performant protocol in the application-layer. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 9 July 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction 55 2. Terminology 56 3. Background 57 3.1. Motivating use-cases 58 3.2. Anonymity and security guarantees 59 3.3. Basic assumptions 60 4. Protocol description 61 4.1. Server setup 62 4.2. Client setup 63 4.3. Issuance phase 64 4.4. Redemption phase 65 4.4.1. Client info 66 4.4.2. Double-spend protection 67 4.5. Handling errors 68 5. Functionality 69 5.1. Data structures 70 5.1.1. Ciphersuite 71 5.1.2. Keys 72 5.1.3. IssuanceInput 73 5.1.4. IssuanceResponse 74 5.1.5. RedemptionToken 75 5.1.6. RedemptionRequest 76 5.1.7. RedemptionResponse 77 5.2. API functions 78 5.2.1. Generate 79 5.2.2. Issue 80 5.2.3. Process 81 5.2.4. Redeem 82 5.2.5. Verify 83 5.3. Error types 84 6. Security considerations 85 6.1. Unlinkability 86 6.2. One-more unforgeability 87 6.3. Double-spend protection 88 6.4. Additional token metadata 89 6.5. Maximum number of tokens issued 90 7. VOPRF instantiation 91 7.1. Recommended ciphersuites 92 7.2. Protocol contexts 93 7.3. Functionality 94 7.3.1. Generate 95 7.3.2. Issue 96 7.3.3. Process 97 7.3.4. Redeem 98 7.3.5. Verify 99 7.4. Security justification 100 8. Protocol ciphersuites 101 8.1. PP(OPRF2) 102 8.2. PP(OPRF4) 103 8.3. PP(OPRF5) 104 9. Extensions framework policy 105 10. References 106 10.1. Normative References 107 10.2. Informative References 108 Appendix A. Document contributors 109 Authors' Addresses 111 1. Introduction 113 A common problem on the Internet is providing an effective mechanism 114 for servers to derive trust from clients that they interact with. 115 Typically, this can be done by providing some sort of authorization 116 challenge to the client. But this also negatively impacts the 117 experience of clients that regularly have to solve such challenges. 119 To mitigate accessibility issues, a client that correctly solves the 120 challenge can be provided with a cookie. This cookie can be 121 presented the next time the client interacts with the server, instead 122 of performing the challenge. However, this does not solve the 123 problem of reauthorization of clients across multiple domains. Using 124 current tools, providing some multi-domain authorization token would 125 allow linking client browsing patterns across those domains, and 126 severely reduces their online privacy. 128 The Privacy Pass protocol provides a set of cross-domain 129 authorization tokens that protect the client's anonymity in message 130 exchanges with a server. This allows clients to communicate an 131 attestation of a previously authenticated server action, without 132 having to reauthenticate manually. The tokens retain anonymity in 133 the sense that the act of revealing them cannot be linked back to the 134 session where they were initially issued. 136 This document lays out the generic description of the protocol, along 137 with the data and message formats. We detail an implementation of 138 the protocol functionality based on the description of a verifiable 139 oblivious pseudorandom function [I-D.irtf-cfrg-voprf]. 141 This document DOES NOT cover the architectural framework required for 142 running and maintaining the Privacy Pass protocol in the Internet 143 setting. In addition, it DOES NOT cover the choices that are 144 necessary for ensuring that client privacy leaks do not occur. Both 145 of these considerations are covered in a separate document 146 [draft-davidson-pp-architecture]. In addition, 147 [draft-svaldez-pp-http-api] provides an instantiation of this 148 protocol intended for the HTTP setting. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 The following terms are used throughout this document. 158 * Server: A service that provides the server-side functionality 159 required by the protocol. May be referred to as the issuer. 161 * Client: An entity that seeks authorization from a server that 162 supports interactions in the Privacy Pass protocol. 164 * Key: The secret key used by the server for authorizing client 165 data. 167 We assume that all protocol messages are encoded into raw byte format 168 before being sent. We use the TLS presentation language [RFC8446] to 169 describe the structure of protocol data types and messages. 171 3. Background 173 We discuss the core motivation behind the protocol along with the 174 guarantees and assumptions that we make in this document. 176 3.1. Motivating use-cases 178 The Privacy Pass protocol was originally developed to provide 179 anonymous authorization of Tor users. In particular, the protocol 180 allows clients to reveal authorization tokens that they have been 181 issued without linking the authorization to the actual issuance 182 event. This means that the tokens cannot be used to link the 183 browsing patterns of clients that reveal tokens. 185 Beyond these uses-cases, the Privacy Pass protocol is used in a 186 number of practical applications. See [DGSTV18], [TrustTokenAPI], 187 [PrivateStorage], [OpenPrivacy], and [Brave] for examples. 189 3.2. Anonymity and security guarantees 191 Privacy Pass provides anonymity-preserving authorization tokens for 192 clients. Throughout this document, we use the terms "anonymous", 193 "anonymous-preserving" and "anonymity" to refer to the core security 194 guarantee of the protocol. Informally, this guarantee means that any 195 token issued by a server key and subsequently redeemed is 196 indistinguishable from any other token issued under the same key. 198 Privacy Pass also prohibits clients from forging tokens, as otherwise 199 the protocol would have little value as an authorization protocol. 200 Informally, this means any client that is issued "N" tokens under a 201 given server key cannot redeem more than "N" valid tokens. 203 Section 6 elaborates on these protocol anonymity and security 204 requirements. 206 3.3. Basic assumptions 208 We make only a few minimal assumptions about the environment of the 209 clients and servers supporting the Privacy Pass protocol. 211 * At any one time, we assume that the server uses only one 212 configuration containing their ciphersuite choice along with their 213 secret key data. This ensures that all clients are issued tokens 214 under the single key associated with any given epoch. 216 * We assume that the client has access to a global directory of the 217 current public parts of the configurations used the server. 219 The wider ecosystem that this protocol is employed in is described in 220 [draft-davidson-pp-architecture]. 222 4. Protocol description 224 The Privacy Pass protocol is split into two phases that are built 225 upon the functionality described in Section 5 later. 227 The first phase, "issuance", provides the client with unlinkable 228 tokens that can be used to initiate re-authorization with the server 229 in the future. The second phase, "redemption", allows the client to 230 redeem a given re-authorization token with the server that it 231 interacted with during the issuance phase. The protocol must satisfy 232 two cryptographic security requirements known as "unlinkability" and 233 "unforgeability". These requirements are covered in Section 6. 235 4.1. Server setup 237 Before the protocol takes place, the server chooses a ciphersuite and 238 generates a keypair by running "(pkS, skS) = KeyGen()". This 239 configuration must be available to all clients that interact with the 240 server (for the purpose of engaging in a Privacy Pass exchange). We 241 assume that the server has a public (and unique) identity that the 242 client uses to retrieve this configuration. 244 4.2. Client setup 246 The client initialises a global storage system "store" that allows it 247 store the tokens that are received during issuance. The storage 248 system is a map of server identifiers ("server.id") to arrays of 249 stored tokens. We assume that the client knows the server public key 250 "pkS" ahead of time. The client picks a value "m" of tokens to 251 receive during the issuance phase. In 252 [draft-davidson-pp-architecture] we discuss mechanisms that the 253 client can use to ensure that this public key is consistent across 254 the entire ecosystem. 256 4.3. Issuance phase 258 The issuance phase allows the client to receive "m" anonymous 259 authorization tokens from the server. 261 Client(pkS, m) Server(skS, pkS) 262 ------------------------------------------------------------ 263 cInput = Generate(m) 264 req = cInput.req 266 req 267 -------------------> 269 serverResp = Issue(pkS, skS, req) 271 issueResp 272 <------------------- 274 tokens = Process(pkS, cInput, issueResp) 275 store[server.id].push(tokens) 277 4.4. Redemption phase 279 The redemption phase allows the client to anonymously reauthenticate 280 to the server, using data that it has received from a previous 281 issuance phase. 283 Client(info) Server(skS, pkS) 284 ------------------------------------------------------------ 285 token = store[Issue.id].pop() 286 req = Redeem(token, info) 288 req 289 ------------------> 291 if (dsIdx.includes(req.data)) { 292 raise ERR_DOUBLE_SPEND 293 } 294 resp = Verify(pkS, skS, req) 295 if (resp.success) { 296 dsIdx.push(req.data) 297 } 299 resp 300 <------------------ 301 Output resp 303 4.4.1. Client info 305 The client input "info" is arbitrary byte data that is used for 306 linking the redemption request to the specific session. We RECOMMEND 307 that "info" is constructed as the following concatenated byte-encoded 308 data: 310 len(aux) || aux || len(server.id) || server.id || current_time() 312 where "len(x)" is the length of "x" in bytes, and "aux" is arbitrary 313 auxiliary data chosen by the client. The usage of "current_time()" 314 allows the server to check that the redemption request has happened 315 in an appropriate time window. 317 4.4.2. Double-spend protection 319 To protect against clients that attempt to spend a value "req.data" 320 more than once, the server uses an index, "dsIdx", to collect valid 321 inputs it witnesses. Since this store needs to only be optimized for 322 storage and querying, a structure such as a Bloom filter suffices. 323 The storage should be parameterized to live as long as the server 324 keypair that is in use. See Section 6 for more details. 326 4.5. Handling errors 328 It is possible for the API functions from Section 5.2 to return one 329 of the errors indicated in Section 5.3 rather than their expected 330 value. In these cases, we assume that the entire protocol aborts. 332 5. Functionality 334 This section details the data types and API functions that are used 335 to construct the protocol in Section 4. 337 We provide an explicit instantiation of the Privacy Pass API in 338 Section 7.3, based on the public API provided in 339 [I-D.irtf-cfrg-voprf]. 341 5.1. Data structures 343 The following data structures are used throughout the Privacy Pass 344 protocol and are written in the TLS presentation language [RFC8446]. 345 It is intended that any of these data structures can be written into 346 widely-adopted encoding schemes such as those detailed in TLS 347 [RFC8446], CBOR [RFC7049], and JSON [RFC7159]. 349 5.1.1. Ciphersuite 351 The "Ciphersuite" enum provides identifiers for each of the supported 352 ciphersuites of the protocol. Some initial values that are supported 353 by the core protocol are described in Section 8. Note that the list 354 of supported ciphersuites may be expanded by extensions to the core 355 protocol description in separate documents. 357 5.1.2. Keys 359 We use the following types to describe the public and private keys 360 used by the server. 362 opaque PublicKey<1..2^16-1> 363 opaque PrivateKey<1..2^16-1> 365 5.1.3. IssuanceInput 367 The "IssuanceInput" struct describes the data that is initially 368 generated by the client during the issuance phase. 370 Firstly, we define sequences of bytes that partition the client 371 input. 373 opaque Internal<1..2^16-1> 374 opaque IssuanceRequest<1..2^16-1> 376 These data types represent members of the wider "IssuanceInput" data 377 type. 379 struct { 380 Internal data[m] 381 IssuanceRequest req[m] 382 } IssuanceInput; 384 Note that a "IssuanceInput" contains equal-length arrays of 385 "Internal" and "IssuanceRequest" types corresponding to the number of 386 tokens that should be issued. 388 5.1.4. IssuanceResponse 390 Firstly, the "IssuedToken" type corresponds to a single sequence of 391 bytes that represents a single issued token received from the server. 393 opaque IssuedToken<1..2^16-1> 395 Then an "IssuanceResponse" corresponds to a collection of 396 "IssuedTokens" as well as a sequence of bytes "proof". 398 struct { 399 IssuedToken tokens[m] 400 opaque proof<1..2^16-1> 401 } 403 The value of "m" is equal to the length of the "IssuanceRequest" 404 vector sent by the client. 406 5.1.5. RedemptionToken 408 The "RedemptionToken" struct contains the data required to generate 409 the client message in the redemption phase of the Privacy Pass 410 protocol. 412 struct { 413 opaque data<1..2^16-1>; 414 opaque issued<1..2^16-1>; 415 } RedemptionToken; 417 5.1.6. RedemptionRequest 419 The "RedemptionRequest" struct consists of the data that is sent by 420 the client during the redemption phase of the protocol. 422 struct { 423 opaque data<1..2^16-1>; 424 opaque tag<1..2^16-1>; 425 opaque info<1..2^16-1>; 426 } RedemptionRequest; 428 5.1.7. RedemptionResponse 430 The "RedemptionResponse" struct corresponds to a boolean value that 431 indicates whether the "RedemptionRequest" sent by the client is 432 valid. It can also contain any associated data. 434 struct { 435 boolean success; 436 opaque ad<1..2^16-1>; 437 } RedemptionResponse; 439 5.2. API functions 441 The following functions wrap the core of the functionality required 442 in the Privacy Pass protocol. For each of the descriptions, we 443 essentially provide the function signature, leaving the actual 444 contents to be defined by specific instantiations or extensions of 445 the protocol. 447 5.2.1. Generate 449 A function run by the client to generate the initial data that is 450 used as its input in the Privacy Pass protocol. 452 Inputs: 454 * "m": A "uint8" value corresponding to the number of Privacy Pass 455 tokens to generate. 457 Outputs: 459 * "input": An "IssuanceInput" struct. 461 5.2.2. Issue 463 A function run by the server to issue valid redemption tokens to the 464 client. 466 Inputs: 468 * "pkS": A server "PublicKey". 470 * "skS": A server "PrivateKey". 472 * "req": An "IssuanceRequest" struct. 474 Outputs: 476 * "resp": An "IssuanceResponse" struct. 478 5.2.3. Process 480 Run by the client when processing the server response in the issuance 481 phase of the protocol. 483 Inputs: 485 * "pkS": An server "PublicKey". 487 * "input": An "IssuanceInput" struct. 489 * "resp": An "IssuanceResponse" struct. 491 Outputs: 493 * "tokens": A vector of "RedemptionToken" structs, whose length is 494 equal to length of the internal "ServerEvaluation" vector in the 495 "IssuanceResponse" struct. 497 Throws: 499 * "ERR_PROOF_VALIDATION" (Section 5.3) 501 5.2.4. Redeem 503 Run by the client in the redemption phase of the protocol to generate 504 the client's message. 506 Inputs: 508 * "token": A "RedemptionToken" struct. 510 * "info": An "opaque<1..2^16-1>" type corresponding to data that is 511 linked to the redemption. See Section 4.4.1 for advice on how to 512 construct this. 514 Outputs: 516 * "req": A "RedemptionRequest" struct. 518 5.2.5. Verify 520 Run by the server in the redemption phase of the protocol. 521 Determines whether the data sent by the client is valid. 523 Inputs: 525 * "pkS": An server "PublicKey". 527 * "skS": An server "PrivateKey". 529 * "req": A "RedemptionRequest" struct. 531 Outputs: 533 * "resp": A "RedemptionResponse" struct. 535 5.3. Error types 537 * "ERR_PROOF_VALIDATION": Error occurred when a client attempted to 538 verify the proof that is part of the server's response. 540 * "ERR_DOUBLE_SPEND": Error occurred when a client has attempted to 541 redeem a token that has already been used for authorization. 543 6. Security considerations 545 We discuss the security requirements that are necessary to uphold 546 when instantiating the Privacy Pass protocol. In particular, we 547 focus on the security requirements of "unlinkability", and 548 "unforgeability". Informally, the notion of unlinkability is 549 required to preserve the anonymity of the client in the redemption 550 phase of the protocol. The notion of unforgeability is to protect 551 against an adversarial client that may look to subvert the security 552 of the protocol. 554 Both requirements are modelled as typical cryptographic security 555 games, following the formats laid out in [DGSTV18] and [KLOR20]. 557 Note that the privacy requirements of the protocol are covered in the 558 architectural framework document [draft-davidson-pp-architecture]. 560 6.1. Unlinkability 562 Formally speaking the security model is the following: 564 * The adversary runs the server setup and generates a keypair "(pkS, 565 skS)". 567 * The adversary specifies a number "Q" of issuance phases to 568 initiate, where each phase "i in range(Q)" consists of "m_i" Issue 569 evaluations. 571 * The adversary runs "Issue" using the keypair that it generated on 572 each of the client messages in the issuance phase. 574 * When the adversary wants, it stops the issuance phase, and a 575 random number "l" is picked from "range(Q)". 577 * A redemption phase is initiated with a single token with index "i" 578 randomly sampled from "range(m_l)". 580 * The adversary guesses an index "l_guess" corresponding to the 581 index of the issuance phase that it believes the redemption token 582 was received in. 584 * The adversary succeeds if "l == l_guess". 586 The security requirement is that the adversary has only a negligible 587 probability of success greater than "1/Q". 589 6.2. One-more unforgeability 591 The one-more unforgeability requirement states that it is hard for 592 any adversarial client that has received "m" valid tokens from the 593 issuance phase to redeem "m+1" of them. In essence, this requirement 594 prevents a malicious client from being able to forge valid tokens 595 based on the Issue responses that it sees. 597 The security model roughly takes the following form: 599 * The adversary specifies a number "Q" of issuance phases to 600 initiate with the server, where each phase "i in range(Q)" 601 consists of "m_i" server evaluation. Let "m = sum(m_i)" where "i 602 in range(Q)". 604 * The adversary receives "Q" responses, where the response with 605 index "i" contains "m_i" individual tokens. 607 * The adversary initiates "m_adv" redemption sessions with the 608 server and the server verifies that the sessions are successful 609 (return true), and that each request includes a unique token. The 610 adversary succeeds in "m_succ =< m_adv" redemption sessions. 612 * The adversary succeeds if "m_succ > m". 614 The security requirement is that the adversarial client has only a 615 negligible probability of succeeding. 617 Note that [KLOR20] strengthens the capabilities of the adversary, in 618 comparison to the original work of [DGSTV18]. In [KLOR20], the 619 adversary is provided with oracle access that allows it to verify 620 that the server responses in the issuance phase are valid. 622 6.3. Double-spend protection 624 All issuing servers should implement a robust, global storage-query 625 mechanism for checking that tokens sent by clients have not been 626 spent before. Such tokens only need to be checked for each server 627 individually. This prevents clients from "replaying" previous 628 requests, and is necessary for achieving the unforgeability 629 requirement. 631 6.4. Additional token metadata 633 Some use-cases of the Privacy Pass protocol benefit from associating 634 a limited amount of metadata with tokens that can be read by the 635 server when a token is redeemed. Adding metadata to tokens can be 636 used as a vector to segment the anonymity of the client in the 637 protocol. Therefore, it is important that any metadata that is added 638 is heavily limited. 640 Any additional metadata that can be added to redemption tokens should 641 be described in the specific protocol instantiation. Note that any 642 additional metadata will have to be justified in light of the privacy 643 concerns raised above. For more details on the impacts associated 644 with segmenting user privacy, see [draft-davidson-pp-architecture]. 646 Any metadata added to tokens will be considered either "public" or 647 "private". Public metadata corresponds to unmodifiable bits that a 648 client can read. Private metadata corresponds to unmodifiable 649 private bits that should be obscured to the client. 651 Note that the instantiation in Section 7 provides randomized 652 redemption tokens with no additional metadata for an server with a 653 single key. 655 6.5. Maximum number of tokens issued 657 Servers SHOULD impose a hard ceiling on the number of tokens that can 658 be issued in a single issuance phase to a client. If there is no 659 limit, malicious clients could abuse this and cause excessive 660 computation, leading to a Denial-of-Service attack. 662 7. VOPRF instantiation 664 In this section, we show how to instantiate the functional API in 665 Section 5 with the VOPRF protocol described in [I-D.irtf-cfrg-voprf]. 666 Moreover, we show that this protocol satisfies the security 667 requirements laid out in Section 6, based on the security proofs 668 provided in [DGSTV18] and [KLOR20]. 670 7.1. Recommended ciphersuites 672 The RECOMMENDED server ciphersuites are as follows: detailed in 673 [I-D.irtf-cfrg-voprf]: 675 * OPRF(curve448, SHA-512) (ID = 0x0002); 677 * OPRF(P-384, SHA-512) (ID = 0x0004); 679 * OPRF(P-521, SHA-512) (ID = 0x0005). 681 We deliberately avoid the usage of smaller ciphersuites (associated 682 with P-256 and curve25519) due to the potential to reduce security to 683 unfavourable levels via static Diffie Hellman attacks. See 684 [I-D.irtf-cfrg-voprf] for more details. 686 7.2. Protocol contexts 688 Note that we must run the verifiable version of the protocol in 689 [I-D.irtf-cfrg-voprf]. Therefore the "server" takes the role of the 690 "Server" running in "modeVerifiable". In other words, the "server" 691 runs "(ctxtI, pkS) = SetupVerifiableServer(suite)"; where "suite" is 692 one of the ciphersuites in Section 7.1, "ctxt" contains the internal 693 VOPRF server functionality and secret key "skS", and "pkS" is the 694 server public key. Likewise, run "ctxtC = 695 SetupVerifiableClient(suite)" to generate the Client context. 697 7.3. Functionality 699 We instantiate each functions using the API functions in 700 [I-D.irtf-cfrg-voprf]. Note that we use the framework mentioned in 701 the document to allow for batching multiple tokens into a single 702 VOPRF evaluation. For the explicit signatures of each of the 703 functions, refer to Section 5. 705 7.3.1. Generate 707 def Generate(m): 708 tokens = [] 709 blindedTokens = [] 710 for i in range(m): 711 x = random_bytes() 712 (token, blindedToken) = Blind(x) 713 token[i] = token 714 blindedToken[i] = blindedToken 715 return IssuanceInput { 716 internal: tokens, 717 req: blindedTokens, 718 } 720 7.3.2. Issue 722 For this functionality, note that we supply multiple tokens in "req" 723 to "Evaluate". This allows batching a single proof object for 724 multiple evaluations. While the construction in 725 [I-D.irtf-cfrg-voprf] only permits a single input, we follow the 726 advice for providing vectors of inputs. 728 def Issue(pkS, skS, req): 729 Ev = Evaluate(skS, pkS, req) 730 return IssuanceResponse { 731 tokens: Ev.elements, 732 proof: Ev.proof, 733 } 735 7.3.3. Process 737 Similarly to "Issue", we follow the advice for providing vectors of 738 inputs to the "Unblind" function for verifying the batched proof 739 object. 741 Process(pkS, input, resp): 742 unblindedTokens = Unblind(pkS, input.data, input.req, resp) 743 redemptionTokens = [] 744 for bt in unblindedTokens: 745 rt = RedemptionToken { data: input.data, issued: bt } 746 redemptionTokens[i] = rt 747 return redemptionTokens 749 7.3.4. Redeem 751 def Redeem(token, info): 752 tag = Finalize(token.data, token.issued, info) 753 return RedemptionRequest { 754 data: data, 755 tag: tag, 756 info: info, 757 } 759 7.3.5. Verify 761 def Verify(pkS, skS, req): 762 resp = VerifyFinalize(skS, pkS, req.data, req.info, req.tag) 763 Output RedemptionResponse { 764 success: resp 765 } 767 7.4. Security justification 769 The protocol devised in Section 4, coupled with the API instantiation 770 in Section 7.3, are equivalent to the protocol description in 771 [DGSTV18] and [KLOR20] from a security perspective. In [DGSTV18], it 772 is proven that this protocol satisfies the security requirements of 773 unlinkability (Section 6.1) and unforgeability (Section 6.2). 775 The unlinkability property follows unconditionally as the view of the 776 adversary in the redemption phase is distributed independently of the 777 issuance phase. The unforgeability property follows from the one- 778 more decryption security of the ElGamal cryptosystem [DGSTV18]. In 779 [KLOR20] it is also proven that this protocol satisfies the stronger 780 notion of unforgeability, where the adversary is granted a 781 verification oracle, under the chosen-target Diffie-Hellman 782 assumption. 784 Note that the existing security proofs do not leverage the VOPRF 785 primitive as a black-box in the security reductions. Instead, it 786 relies on the underlying operations in a non-black-box manner. 787 Hence, an explicit reduction from the generic VOPRF primitive to the 788 Privacy Pass protocol would strengthen these security guarantees. 790 8. Protocol ciphersuites 792 The ciphersuites that we describe for the Privacy Pass protocol are 793 derived from the core instantiations of the protocol (such as in 794 Section 7). 796 In each of the ciphersuites below, the maximum security provided 797 corresponds to the maximum difficulty of computing a discrete 798 logarithm in the group. Note that the actual security level MAY be 799 lower. See the security considerations in [I-D.irtf-cfrg-voprf] for 800 examples. 802 8.1. PP(OPRF2) 804 * OPRF2 = OPRF(curve448, SHA-512) 806 * ID = 0x0001 808 * Maximum security provided: 224 bits 810 8.2. PP(OPRF4) 812 * OPRF4 = OPRF(P-384, SHA-512) 814 * ID = 0x0002 816 * Maximum security provided: 192 bits 818 8.3. PP(OPRF5) 820 * OPRF5 = OPRF(P-521, SHA-512) 822 * ID = 0x0003 824 * Maximum security provided: 256 bits 826 9. Extensions framework policy 828 The intention with providing the Privacy Pass API in Section 5 is to 829 allow new instantiations of the Privacy Pass protocol. These 830 instantiations may provide either modified VOPRF constructions, or 831 simply implement the API in a completely different way. 833 Extensions to this initial draft SHOULD be specified as separate 834 documents taking one of two possible routes: 836 * Produce new VOPRF-like primitives that use the same public API 837 provided in [I-D.irtf-cfrg-voprf] to implement the Privacy Pass 838 API, but with different internal operations. 840 * Implement the Privacy Pass API in a different way to the proposed 841 implementation in Section 7. 843 If an extension requires changing the generic protocol description as 844 described in Section 4, then the change may have to result in changes 845 to the draft specification here also. 847 Each new extension that modifies the internals of the protocol in 848 either of the two ways MUST re-justify that the extended protocol 849 still satisfies the security requirements in Section 6. Protocol 850 extensions MAY put forward new security guarantees if they are 851 applicable. 853 The extensions MUST also conform with the extension framework policy 854 as set out in the architectural framework document. For example, 855 this may concern any potential impact on client anonymity that the 856 extension may introduce. 858 10. References 860 10.1. Normative References 862 [draft-davidson-pp-architecture] 863 Davidson, A., "Privacy Pass: Architectural Framework", 864 n.d., . 867 [draft-svaldez-pp-http-api] 868 Valdez, S., "Privacy Pass: HTTP API", n.d., 869 . 872 [I-D.irtf-cfrg-voprf] 873 Davidson, A., Faz-Hernandez, A., Sullivan, N., and C. 874 Wood, "Oblivious Pseudorandom Functions (OPRFs) using 875 Prime-Order Groups", Work in Progress, Internet-Draft, 876 draft-irtf-cfrg-voprf-05, 2 November 2020, 877 . 880 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 881 Requirement Levels", BCP 14, RFC 2119, 882 DOI 10.17487/RFC2119, March 1997, 883 . 885 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 886 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 887 . 889 10.2. Informative References 891 [Brave] "Brave Rewards", n.d., . 893 [DGSTV18] "Privacy Pass, Bypassing Internet Challenges Anonymously", 894 n.d., . 897 [KLOR20] "Anonymous Tokens with Private Metadata Bit", n.d., 898 . 900 [OpenPrivacy] 901 "Token Based Services - Differences from PrivacyPass", 902 n.d., . 905 [PrivateStorage] 906 Steininger, L., "The Path from S4 to PrivateStorage", 907 n.d., . 910 [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object 911 Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, 912 October 2013, . 914 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 915 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 916 2014, . 918 [TrustTokenAPI] 919 WICG, ., "Trust Token API", n.d., 920 . 922 Appendix A. Document contributors 924 * Alex Davidson (alex.davidson92@gmail.com) 926 * Sofia Celi (cherenkov@riseup.net) 928 * Christopher Wood (caw@heapingbits.net) 930 Authors' Addresses 932 Sofía Celi 933 Cloudflare 934 Lisbon 935 Portugal 937 Email: sceli@cloudflare.com 939 Alex Davidson 940 LIP 941 Lisbon 942 Portugal 944 Email: alex.davidson92@gmail.com 946 Armando Faz-Hernandez 947 Cloudflare 948 101 Townsend St 949 San Francisco, 950 United States of America 952 Email: armfazh@cloudflare.com