idnits 2.17.1 draft-mcfadden-pp-centralization-problem-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 128: '..., a strict bound SHOULD be applied to ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1269 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 304, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 November 2, 2020 4 Expires: May 2, 2021 6 Privacy Pass: Centralization Problem Statement 7 draft-mcfadden-pp-centralization-problem-00.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 May 2, 2021. 32 Copyright Notice 34 Copyright (c) 2020 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 and mitigations associated with 50 strict upper bounds on the number of Privacy Pass servers in the 51 proposed Privacy Pass ecosystem. It documents a proposed problem 52 statement. 54 Table of Contents 56 1. Introduction...................................................2 57 2. Potential Privacy Concerns.....................................3 58 3. Centralization in Privacy Pass - Problem Statement.............4 59 3.1. Architectural Problems....................................4 60 3.2. Engineering Problems......................................5 61 3.3. Practical Problems........................................6 62 4. Problem Statement and Potential for Mitigations................6 63 4.1. Problem Statement.........................................6 64 4.2. Potential Mitigations.....................................6 65 5. Security Considerations........................................7 66 6. IANA Considerations............................................7 67 7. References.....................................................7 68 7.1. Informative References....................................7 69 8. Acknowledgments................................................7 71 1. Introduction 73 The Privacy Pass protocol provides a set of cross-domain 74 authorization tokens that protect the client's anonymity in message 75 exchanges with a server. This allows clients to communicate an 76 attestation of a previously authenticated server action, without 77 having to reauthenticate with user intervention. The tokens retain 78 anonymity when this is defined as the act of revealing them cannot 79 be linked back to the session where they were initially issued. 81 The protocol itself in defined in [1] and the architectural 82 framework is in [2]. 84 The architecture document leaves for a later time the issue of 85 server centralization. This document is a discussion of the 86 problems related to server centralization in Privacy Pass, the 87 impact of centralization on the protocol's privacy goals, and some 88 potential mitigations for the problem. 90 An important feature of the Privacy Pass Architecture is the concept 91 of the anonymity set of each individual client. The Privacy Pass 92 ecosystem has a set of servers which issue tokens to clients which 93 can then be redeemed at the application layer for authentication. 95 Trust is an important component in Privacy Pass. The servers have to 96 publish their public keys and details of the ciphersuite they are 97 using. It is necessary to publish these in a globally consistent, 98 tamper-proof data structure. Clients that use the same registry of 99 server information need to coordinate in some way to validate that 100 they have the same view of the registry and its data. 102 Four server running modes are discussed in [2]. Common to all four 103 is a discussion of the need to set an upper limit on the number of 104 servers that are allowed. The motivation for limiting the number of 105 servers is that there is a correlation between larger numbers of 106 servers and dilution of privacy. 108 2. Potential Privacy Concerns 110 When a client redeems a token in Privacy Pass, there is very little 111 information in the token itself other than the key that was used to 112 sign the token. A key feature of the protocol is that any client can 113 only remain private relative to the entire space of users using the 114 protocol. 116 In three of the four server running modes, a Privacy Pass verifier 117 is able to trigger redemption for any of the available servers. The 118 greater the number of servers, the greater the loss in anonymity. 120 The architecture document [2] provides an example where, if there 121 are 32 servers, then the verifier learns 32 bits of information 122 about the client. In certain circumstances, having that much 123 information about the client can lead to the client being uniquely 124 identified and the goals of Privacy Pass thwarted. As a result, the 125 architecture document supplies the following mitigation: 127 "In cases where clients can hold tokens for all servers at any given 128 time, a strict bound SHOULD be applied to the active number of 129 servers in the ecosystem." [2] 131 Putting restrictions on the number of redemption tokens at the 132 client is considered. It is not clear whether reducing the number of 133 redemption tokens would continue to meet Privacy Pass' stated 134 privacy goals. However, establishing control of the client, and the 135 number of tokens it has, is far more difficult than restricting the 136 number of active servers. 138 3. Centralization in Privacy Pass - Problem Statement 140 For Privacy Pass to succeed clients must be able to acquire tokens 141 that they can later redeem with greater privacy and anonymity than 142 in typical manual or user-mediated authentication. This document 143 does not discuss the goals of privacy or anonymity. Instead, it 144 identifies a problem related to the upper bound in number of servers 145 that affects the Privacy Pass ecosystem. 147 For the purposes of this draft, "server centralization" is the 148 strict limit or upper bound in the number of servers available from 149 which a client can acquire a token for later redemption. 151 The architecture draft specifies an upper limit of four for this 152 upper bound. 154 The problem statement for Privacy pass can be summarized: an upper 155 bound to available Privacy Pass servers creates architectural, 156 engineering and practical problems for the deployment of the 157 protocol. Any successful deployment of Privacy Pass must find 158 mitigations for these problems. 160 3.1. Architectural Problems 162 Centralization is a problem space that has been exhaustively 163 explored by others; not least of which in the IETF itself. The now 164 expired IAB draft [3]] discussed six separate issues related to 165 centralization and several of them appear to apply to Privacy Pass. 166 Those issues were: 168 o single points of failuyre 170 o surveillance 172 o concentration of information 174 o effect scope 176 o interaction with other issues 178 o the effect on differing expectations and jurisdictions 180 Having a very limited number of servers available creates an 181 architectural strain on avoiding single points of failure. While 182 the Privacy Pass architecture document does specify up to four 183 servers, this is a very small number for, potentially, billions of 184 possible users. The context of Privacy Pass appears to assume that 185 the protocol is only used in "human-to-server" applications. 186 However, it is possible to imagine it being used in situations where 187 the client is not a human, but some other device - either acting on 188 behalf of a human or autonomously. Strict limitations on the number 189 of servers poses the question of how the Privacy Pass architecture 190 can scale in the presence of a large client base. 192 The Privacy Pass architecture, by limiting the number of servers, 193 also concentrates information and potentially limits the ability for 194 other competing providers of the token generating services. By 195 concentrating the information in a small number of servers, a 196 problem appears when there are machine learning opportunities to 197 collect and process data about clients requesting tokens. The 198 problem also appears when the issuing server also has access to 199 other metadata or requests from the client (for instance, DNS 200 resolution requests or cached objects returned as part of HTTP 201 requests). 203 A side effect of limiting the number of servers is that a 204 significant amount of information ends up being in the control of a 205 small number of entities. A client may trust a Privacy Pass server 206 as send it information about itself in order to request tokens. 207 However, the protocol itself can make no guarantee about the data 208 handling practices of the server operator. A potential protocol 209 design goal should be to minimize the opportunities for abuse by the 210 server operator. Situations outside the control of the protocol may 211 make it so there are pressures to misuse the data concentrated at 212 the small number of servers. 214 3.2. Engineering Problems 216 In the event that a very limited number of servers can be provided 217 while still supporting the goals of the protocol, there is clearly a 218 global scaling problem that needs to be solved. Each server must 219 publish a global, consistent and protected view of its published key 220 and the cryptosystem in use. Without access to that view, the system 221 appears to have no failure mode. 223 With a small number of servers, the ecosystem would likely be 224 dominated by a few providers. With a dominant position in the market 225 these Privacy Pass server operators would have a significant impact 226 on default connectivity parameters in operating systems and 227 browsers. As a result, a change to the way the access mechanism 228 works for a variety of applications would have broad impacts to a 229 wide variety of users. The relationship between engineering and how 230 it affects a broad community of users has a recent example in DNS 231 over HTTPS [4]. 233 3.3. Practical Problems 235 Limits to the number of server operators also results in practical 236 problems outside the protocol. In the event that a small number of 237 server operators appear in the Privacy Pass ecosystem, and a large 238 number of clients enter into trust relationships with those 239 operators, what happens when those operators are acquired by other 240 organizations that have different data handling and privacy policies 241 than the original operator? 243 With the requirement for a small number of operators, the 244 architecture also doesn't consider the possibility that an 245 organization or government could require Privacy Pass and the use of 246 a particular set of servers. Such a requirement could potentially 247 turn the goals of Privacy Pass against itself. 249 4. Problem Statement and Potential for Mitigations 251 4.1. Problem Statement 253 An upper bound to available Privacy Pass servers creates 254 architectural, engineering and practical problems for the deployment 255 of the protocol. Any successful deployment of Privacy Pass must find 256 mitigations for these problems. 258 4.2. Potential Mitigations 260 The motivation for having an upper bound to available Privacy Pass 261 servers is to limit the amount of information that could be gathered 262 because a client could be forced to redeem tokens for any issuing 263 key. A large number of keys means a greater about of information 264 exposed. 266 One alternative to limiting the number of servers is to constrain 267 the clients so that they only possess redemption tokens for a small 268 number of servers. This potential mitigation doesn't address how the 269 tokens might be cached, but it does discuss how the limitation might 270 be implemented. However, there is much engineering experience to 271 suggest that making a limitation work in a very large number of 272 clients is a much greater engineering and deployment problem than 273 placing the restriction in the server. 275 If the motivation for restricting the number of servers is essential 276 for Privacy Pass - and the mitigations at either the server or 277 client are difficult to overcome - it is hard to understand where 278 the mitigations for the problem statement will emerge. 280 5. Security Considerations 282 This document is all about security considerations for Privacy Pass. 283 In particular, it addresses the very specific problem associated 284 with centralization of Privacy Pass servers. 286 6. IANA Considerations 288 This memo contains no instructions or requests for IANA. The authors 289 continue to appreciate the efforts of IANA staff in support of the 290 IETF. 292 7. References 294 7.1. Informative References 296 [1] Davidson, A. (Editor) "Privacy Pass: The Protocol", 297 Internet-Draft, https://datatracker.ietf.org/doc/draft-davidson-pp- 298 protocol/ July 2020 300 [2] Davidson, A. (Editor) "Privacy Pass: Architectural 301 Framework", Internet-Draft, https://datatracker.ietf.org/doc/draft- 302 davidson-pp-protocol/ July 2020 304 [3] Arkko, J., Trammell, B., Nottingham, M, Huitema, C., 305 Thomson, M., Faber, T., Tantsura, J., ten Oever, N., (editors), 306 Internet-Draft (expired), https://datatracker.ietf.org/doc/draft- 307 arkko-iab-internet-consolidation/ July 2019 309 [4] Hoffman, P., McManus, P. (editors), RFC 8484, "DNS Queries 310 over HTTPS (DoH), January 2019 312 8. Acknowledgments 314 The goal of this draft is to meet the requirement in the charter of 315 Privacy Pass that states: "Risk assessment for centralization in 316 Privacy Pass deployments for multiple design options - February 2021." 317 In particular, the author would like to thank the many speakers at the 318 March and July 2020 Privacy Pass working group meetings who expressed 319 reservations about the centralization features of the protocol design. 321 This document was prepared using 2-Word-v2.0.template.dot. 323 Authors' Addresses 325 Mark McFadden 326 Internet policy advisors, ltd 327 Chepstow, Wales, United Kingdom 329 Email: mark@internetpolicyadvisors.com