idnits 2.17.00 (12 Aug 2021) /tmp/idnits40523/draft-mcfadden-pp-centralization-problem-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (March 7, 2022) is 68 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ID.ietf-privacypass-protocol-02' on line 84 -- Looks like a reference, but probably isn't: 'ID.ietf-privacypass-architecture-02' on line 173 -- Looks like a reference, but probably isn't: 'RFC2119' on line 139 -- Looks like a reference, but probably isn't: 'RFC8174' on line 139 -- Looks like a reference, but probably isn't: 'I-D.arkko-arch-infrastructure-centralisation-00' on line 208 == Unused Reference: '1' is defined on line 385, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 390, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 396, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-privacypass-protocol-02 == Outdated reference: A later version (-03) exists of draft-ietf-privacypass-architecture-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Privacy Pass M. McFadden 2 Internet Draft internet policy advisors, llc 3 Intended status: Informational March 7, 2022 4 Expires: September 7, 2022 6 Privacy Pass: Centralization Problem Statement 7 draft-mcfadden-pp-centralization-problem-03.txt 9 Status of this Memo 11 This Internet-Draft is submitted in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on September 7, 2022. 32 Copyright Notice 34 Copyright (c) 2022 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 Abstract 49 This document discusses the problems associated with strict upper 50 bounds on the number of Privacy Pass servers in the proposed Privacy 51 Pass ecosystem. It documents a proposed problem statement. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Key Role Definitions - Terminology.............................3 57 3. Potential Privacy Concerns.....................................4 58 4. Centralization in Privacy Pass - Problem Statement.............5 59 4.1. Architectural Problems....................................5 60 4.2. Engineering Problems......................................6 61 4.3. Practical Problems........................................6 62 5. Problem Statement and Potential for Mitigations................7 63 5.1. Problem Statement.........................................7 64 5.2. Potential Mitigations.....................................7 65 5.3. Redemption Contexts as a Mitigation.......................8 66 5.4. Implementation Base as a Mitigation.......................8 67 6. Security Considerations........................................9 68 7. IANA Considerations............................................9 69 8. References.....................................................9 70 8.1. Normative References......................................9 71 8.2. Informative References....................................9 72 9. Acknowledgments................................................9 74 1. Introduction 76 The Privacy Pass protocol provides a set of cross-domain 77 authorization tokens that protect the client's anonymity in message 78 exchanges with a server. This allows clients to communicate an 79 attestation of a previously authenticated server action, without 80 having to reauthenticate manually. The tokens retain anonymity in 81 the sense that the act of revealing them cannot be linked back to 82 the session where they were initially issued. 84 The protocol itself in defined in [ID.ietf-privacypass-protocol-02] 85 and the architectural framework is in [ID.ietf-privacypass- 86 architecture-02]. 88 The architecture document provides a concise representation of the 89 roles in the Privacy Pass ecosystem, which is repeated for reference 90 here: 92 Origin Client Attester Issuer 93 /----------------------------------------------------------------- 94 --- 95 | /-----------------------------------------\ 96 | Challenge ----> Attest ---> | 97 | | TokenRequest ---------------> | 98 | Redemption | (validate) | 99 Issuance 100 | Flow | (evaluate) | 101 Flow 102 | | <------------------- TokenResponse | 103 | <--- Response | | 104 | \-----------------------------------------/ 105 \----------------------------------------------------------------- 106 --- 108 Figure 1: Privacy Pass Roles and Flows 110 An important feature of the Privacy Pass Architecture is the concept 111 of the anonymity set of each individual client. The Privacy Pass 112 ecosystem has a set of issuers which issue tokens to clients which 113 can then be redeemed in the Privacy Pass redemption process for 114 authentication. 116 Trust is an important component in Privacy Pass. The issuers have to 117 publish their public keys and details of the ciphersuite they are 118 using. It is necessary to publish these in a globally consistent, 119 tamper-proof data structure. Clients that use the same registry of 120 server information need to coordinate in some way to validate that 121 they have the same view of the registry and its data. 123 Having a large number of Issuers results in the possibility that an 124 Origin could learn further information about a Client. The 125 architecture draft [ID.ietf-privacypass-architecture-02] suggests 126 that the mitigation for this should be an upper limit on the number 127 of Issuers that are allowed in the Privacy Pass ecosystem. The 128 motivation for limiting the number of Issuers is that there is a 129 correlation between larger numbers of servers and dilution of 130 privacy. 132 2. Key Role Definitions - Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in 137 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 A set of words that are in common use have very specific meaning in 141 the context of Privacy Pass. This document relies entirely on the 142 draft architecture [ID.ietf-privacypass-architecture-02] for the 143 definition of the following: 145 Client - An entity that seeks authorization to an Origin. 147 Origin - An entity that challenges Clients for tokens. 149 Issuer - An entity that issues tokens to Clients for properties 150 attested to by the Attester. 152 Attester - An entity that attests to properties of Client for the 153 purposes of token issuance. 155 3. Potential Privacy Concerns 157 When a Client redeems a token in Privacy Pass, there is very little 158 information in the token itself other than the key that was used to 159 sign the token. A key feature of the protocol is that any Client can 160 only remain private relative to the entire space of users using the 161 protocol. 163 The architecture document, [ID.ietf-privacypass-architecture-02], 164 provides an example where, if there are 32 Issuers, then Origins 165 learn 32 bits of information about the Client. In certain 166 circumstances, having that much information about the Client can 167 lead to the client being uniquely identified and the goals of 168 Privacy Pass thwarted. As a result, the architecture document 169 supplies the following mitigation: 171 "In cases where clients can hold tokens for all servers at any given 172 time, a strict bound SHOULD be applied to the active number of 173 Issuers in the ecosystem. [ID.ietf-privacypass-architecture-02]." 175 Putting restrictions on the number of redemption tokens at the 176 client is considered. However, establishing control of the Client, 177 and the number of tokens it has, is far more difficult than 178 restricting the number of active Issuers. 180 4. Centralization in Privacy Pass - Problem Statement 182 For Privacy Pass to succeed Clients must be able to acquire tokens 183 that they can later redeem with greater privacy and anonymity. This 184 document does not discuss the goals of privacy or anonymity. 185 Instead, it identifies a problem related to the upper bound in 186 number of servers that affects the Privacy Pass ecosystem. 188 For the purposes of this draft, "server centralization" is the 189 strict limit or upper bound in the number of Issuers available from 190 which a Client can acquire a token for later redemption. 192 The architecture draft specifies an upper limit of four for this 193 upper bound. 195 The problem statement for Privacy pass can be summarized: an upper 196 bound to available Privacy Pass Issuers creates architectural, 197 engineering and practical problems for the deployment of the 198 protocol. Any successful deployment of Privacy Pass must find 199 mitigations for these problems. 201 4.1. Architectural Problems 203 Centralization is a problem space that has been exhaustively 204 explored by others; not least of which in the IETF itself. The 205 current draft on avoiding Internet centralization [I-D.nottingham- 206 avoiding-internet-centralization-02] provides a useful guide to 207 understand why centralization is undesirable. The now expired IAB 208 draft, [I-D.arkko-arch-infrastructure-centralisation-00], discussed 209 six separate issues related to centralization and several of them 210 appear to apply to Privacy Pass. 212 Having a very limited number of servers available creates an 213 architectural strain on avoiding single points of failure. While 214 the Privacy Pass architecture document does specify up to four 215 servers, this is a very small number for, potentially, billions of 216 possible users. And this assumes that the protocol is only used in 217 "human-to-server" applications and not in situations where the 218 client is not a human but some other device - either acting on 219 behalf of human or autonomously. Strict limitations on the number of 220 servers poses the question of how the Privacy Pass architecture can 221 scale in the presence of a large user base. 223 The Privacy Pass architecture, by limiting the number of servers, 224 also concentrates information and potentially limits the ability for 225 other competing providers of the token generating services. By 226 concentrating the information in a small number of servers, a 227 problem appears when there are machine learning opportunities to 228 collect and process data about clients requesting tokens. 230 A side effect of limiting the number of servers is that a 231 significant amount of information ends up being in the control of a 232 small number of entities. A client may trust a Privacy Pass server 233 as send it information about itself in order to request tokens. 234 However, the protocol itself can make no guarantee about the data 235 handling practices of the server operator. Situations outside the 236 control of the protocol may make it so there are pressures to misuse 237 the data concentrated at the small number of servers. 239 4.2. Engineering Problems 241 In the event that a very limited number of servers can be provided 242 while still supporting the goals of the protocol, there is clearly a 243 global scaling problem that needs to be solved. Each server must 244 publish a global, consistent and protected view of its published key 245 and the cryptosystem in use. Without access to that view, the system 246 appears to have no failure mode. 248 With a small number of servers, the ecosystem would likely be 249 dominated by a few providers. With a dominant position in the market 250 these Privacy Pass server operators would have a significant impact 251 on default connectivity parameters in operating systems and 252 browsers. As a result, a change to the way the access mechanism 253 works for a variety of applications would have broad impacts to a 254 wide variety of users. The relationship between engineering and how 255 how centralization affects a broad community of users and uses DNS 256 over HTTP as an example. Another draft [I-D.draft-lazanski- 257 consolidation-03] discusses the technical, economic and security 258 implications of consolidation. 260 4.3. Practical Problems 262 Limits to the number of Issuers also results in practical problems 263 outside the protocol. In the event that a small number of Issuers 264 appear in the Privacy Pass ecosystem, and a large number of clients 265 enter into trust relationships with those operators, what happens 266 when those operators are acquired by other organizations that have 267 different data handling and privacy policies than the original 268 operator? The idea of Issuer churn is discussed in the architecture 269 document, but is limited to discussing ensuring that trusted 270 registries record which Issuers are active in the ecosystem. 272 With the requirement for a small number of Issuers, the architecture 273 also doesn't consider the possibility that an organization or 274 government could require Privacy Pass and the use of a particular 275 set of Issuers. Such a requirement could potentially turn the goals 276 of Privacy Pass against itself. 278 5. Problem Statement and Potential for Mitigations 280 5.1. Problem Statement 282 An upper bound to available Privacy Pass Issuers creates 283 architectural, engineering and practical problems for the deployment 284 of the protocol. Any successful deployment of Privacy Pass must find 285 mitigations for these problems. 287 5.2. Potential Mitigations 289 The motivation for having an upper bound to available Privacy Pass 290 Issuers is to limit the amount of information that could be 291 gathered, because a client could be forced to redeem tokens for any 292 issuing key. A large number of keys, means a greater about of 293 information exposed. 295 One alternative to limiting the number of Issuers is to constrain 296 the Clients so that they only possess redemption tokens for a small 297 number of Issuers. This potential mitigation doesn't address how the 298 tokens might be cached, but it does discuss how the limitation might 299 be implemented. However, there is much engineering experience to 300 suggest that making a limitation work in a very large number of 301 Clients is a much greater engineering and deployment problem than 302 placing the restriction in the Issuer ecosystem. 304 In addition, limiting the number of Issuers increases the impact of 305 failure in the event that there is insufficient redundancy. It is a 306 situation that has impacted other protocols such as OAuth: when a 307 critical provider of services (such as an Issuer) is unavailable or 308 compromised, the impact of the failure affects services beyond the 309 provider of services. In the case of Privacy Pass, failure at the 310 Issuer would require the client to use another trusted Issuer. 311 However, if the Origin trusted a limited number of Issuers, the 312 Origin's service could be rendered unavailable. 314 If the motivation for restricting the number of Issuers is essential 315 for the success of Privacy Pass - and the mitigations at either the 316 Issuer or Client are difficult to overcome - it is hard to 317 understand where the mitigations for the problem statement will 318 emerge. 320 5.3. Redemption Contexts as a Mitigation 322 Contexts are groupings of resources that have shared anonymity and 323 privacy properties. The current architecture statement has a single, 324 global context for redemption. It is this feature that causes the 325 problem outlined in section 4.1 above: with N issuers in the global 326 ecosystem, there are 2^N possible anonymity sets. Adding additional 327 metadata bits increases the number of anonymity sets. 329 The global redemption context results in a requirement of less than 330 ten total issuers in order to maintain anonymity sets of 5,000. 332 One possible mitigation is to limit redemptions to a specific, 333 shared context. Such an approach could limit the information 334 available - and the potential for leakage - to a specific context. 335 This type of solution would rely, in part, on strong 336 security/privacy boundaries between contexts. While information 337 about redemptions in one context wouldn't affect information in 338 another context, this solution depends upon there being no leakage 339 of information between those contexts. 341 While this potential mitigation is suggested as a possible 342 remediation in the Privacy Pass architecture, it is unclear whether 343 it should be a part of the protocol design or it should be left to 344 the application layer to implement. If left to the application 345 layer, there is potential for the anonymity sets to be very small 346 and not meet the privacy goals of the protocol. 348 What is not clear is how the consolidation considerations are 349 affected by the development of a "symmetric mode" for Privacy Pass. 350 The symmetric mode provides optional metadata but will not enable 351 the use of public verifiability. The goal of this change is to 352 remain consistent with work in the W3C. The mode will use the POPRF 353 algorithm which does not change the architectural characteristics 354 considered in this paper. 356 5.4. Implementation Base as a Mitigation 358 Protocol parameterization in Privacy Pass provides a guide to both 359 architecture and implementation. The calculation of the maximum 360 number of Issuers is based on [0.5 * (U/2^(2I)] where U is the user 361 base. 363 The architecture document notes that with an implementation base of 364 5 million users the maximum number of allowed Issuers is about 4. 365 Using the parameterization choices in the architecture draft, 366 increasing the size of the installed base to 50 million users only 367 increases the maximum number of allowed Issuers to about 6. 369 6. Security Considerations 371 This document is all about security considerations for Privacy Pass. 372 In particular, it addresses the very specific problem associated 373 with centralization of Privacy Pass servers. 375 7. IANA Considerations 377 This memo contains no instructions or requests for IANA. The authors 378 continue to appreciate the efforts of IANA staff in support of the 379 IETF. 381 8. References 383 8.1. Normative References 385 [1] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, March 1997. 388 8.2. Informative References 390 [2] Celi, S., Davidson, A., Valdez,S., Wood, C.and A. Faz- 391 Hernandez, "Privacy Pass Protocol Specification", Work in 392 Progress, Internet-Draft, draft-ietf-privacypass-protocol-02, 393 31 January 2022, . 396 [3] Davoidson, A., Iyengar, J, and Wood, C., "Privacy Pass 397 Architectural Framework", [I-D.ietf-privacypass-architecture- 398 02] Work in Progress, Internet-Draft, 31 January 2022, 399 . 402 9. Acknowledgments 404 This document was prepared using 2-Word-v2.0.template.dot. 406 Authors' Addresses 408 Mark McFadden 409 Internet policy advisors, ltd 410 Chepstow, Wales, United Kingdom 412 Email: mark@internetpolicyadvisors.com