idnits 2.17.1 draft-lazanski-consolidation-02.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 2 instances of too long lines in the document, the longest one being 126 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2021) is 1018 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '15' is defined on line 722, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-ietf-tls-esni-07 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Independent Submission D. Lazanski 2 Internet Draft Last Press Label 3 M. McFadden 4 Internet policy advisors, ltd 5 E. Lear 6 Cisco Systems 7 Intended status: Informational July 12, 2021 8 Expires: January 12, 2022 10 Protocol and Engineering Effects of Consolidation 11 draft-lazanski-consolidation-02.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 This Internet-Draft will expire on January 12, 2022. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with 46 respect to this document. Code Components extracted from this 47 document must include Simplified BSD License text as described in 48 Section 4.e of the Trust Legal Provisions and are provided without 49 warranty as described in the Simplified BSD License. 51 Abstract 53 This document contributes to the ongoing discussion surrounding 54 Internet consolidation. Though there has been much interest in the 55 topic, the conversation has waned. This document aims to discuss 56 recent areas of Internet consolidation that are technical, economic 57 and engineering focused and provide some suggestions for advancing 58 the discussion. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Background to Consolidation Issues and the Role of Standards...3 64 3. Overarching Issues Related to Consolidation....................5 65 3.1. Technical.................................................5 66 3.2. Economic..................................................6 67 3.3. Security..................................................7 68 4. Implications of Consolidation on Internet Architecture.........8 69 4.1. The Changing Architecture of the Internet.................8 70 4.2. The End-to-End Principle Redux............................9 71 5. Implications of Consolidation on Protocol Design..............11 72 5.1. Does Protocol Design Really Affect Consolidation?........11 73 5.2. Case Studies in Consolidation and Protocol Design........11 74 5.2.1. DNS over HTTPS (DOH)................................11 75 5.2.2. Encrypted Server Name Indication (eSNI).............12 76 5.2.3. Privacy Pass........................................12 77 6 Potential Technical Risks...............................13 78 6. Actions for the IETF, IRTF and IAB............................14 79 7. Security Considerations.......................................15 80 8. IANA Considerations...........................................15 81 9. Conclusions...................................................15 82 10. References...................................................15 83 10.1. Informative References..................................15 84 11. Acknowledgments..............................................17 86 1. Introduction 88 Internet consolidation has been under discussion for the last 89 several years. The 2019 Internet Society's "Global Internet Report: 90 Consolidation and the Internet Economy" highlighted issues in this 91 topic and kicked started a series of discussions and publications 92 around consolidation. Furthermore, a draft for the Internet 93 Architecture Board (IAB) discussed issues of economic and technical 94 consolidation. [1] Despite community interest, the draft expired 95 without additional work or publication. 97 Further discussions on this issue have stalled in recent months as 98 we have been faced with the Covid-19 pandemic and all of the 99 challenges that this brings to working and living. This draft aims 100 to reengage with the issues of Internet consolidation and bring 101 together current discussions and trends. 103 2. Background to Consolidation Issues and the Role of Standards 105 Internet consolidation is "the process of increasing control over 106 internet infrastructure and services by a small set of 107 organizations." [2] Let us consider two general categories of 108 concentration: "player" and "layer". By player concentration, we 109 mean the aggregating of a market to a small number of providers for 110 a particular service. Layer concentration means the combining of 111 functions within a given layer. An example of "player" concentration 112 would be a relatively small number of email service providers who 113 offer billions of users email service. Or the number of web search 114 providers or even web browser offerings. [3] 116 The Internet is being consolidated at all layers, from the 117 application layer to the network layer. Large companies, like 118 Facebook and Google, account for a significant amount of the content 119 and applications that are used online today. However, several of 120 these large companies are dominating the development of protocols 121 which fundamentally changes the way in which the Internet works and, 122 ultimately, drives the traffic - and data - into the hands of a few 123 companies. For example, Google has 81% of all searches online and 124 94% of all mobile searches as of 2020. [4] 126 Market consolidation is not limited to the Internet. It happens 127 when economies of scale provide highly aggregated firms an 128 advantage. For the last three decades, we have witnessed 129 concentration occurring not only in telecommunications, but in the 130 financial sector as well, just to name one other example.[5] The 131 acceleration of consolidation has been assisted by "cloud" 132 technologies, such as occurred with email. In the case of email, 133 the service providers make use of SMTP to exchange messages, IMAP to 134 provide those messages to a user interface, and HTTP, HTML, and 135 JavaScript to present those messages directly to a user's browser. 137 In other market consolidation cases, fewer Internet standards are in 138 play. In the case of home assistant tools such as the Amazon Echo 139 or Google Home Assistant, communication from these devices to their 140 respective clouds is largely proprietary in nature. In particular, 141 the information models and schemas they use are not exposed to the 142 outside world. This is because the bulk of the service is performed 143 by the cloud, with relatively little processing occurring in the 144 home. This two-sided model eliminates the lengthy standards 145 development process, thereby permitting faster service improvements. 147 On the Internet over previous decades, numerous Internet Service 148 Provider (ISP) markets were subject to deregulation, disaggregation 149 of customers by regulatory requirement, consolidation, and to some 150 extent, re-regulation. 152 Standards have been viewed as a means to prevent barriers to entry. 153 During the 1980s, AT&T was required to abide by standards as part of 154 the consent decree that resolved antitrust litigation, leading to 155 the ability of anyone to connect a telephone to its network. By 156 1994 standards were recognized as a means to prevent technical 157 barriers to trade (TBT) during the Uruguay Round of the World Trade 158 Organization. 160 As mentioned, both the Internet Society and participants of the IETF 161 have recently published on the subject of consolidation. At the 162 IAB's Design Expectations vs. Deployment Reality in Protocol 163 Development Workshop 2019 a handful of the participants discussed 164 concentration and consolidation. [4] Andrew Sullivan looked at three 165 types of concentration in open protocols; web services, network 166 services and standardisation. Both Christian Huitema and Julien 167 Maisonneuve noted concentration, which leads to consolidation, as an 168 effect of economies of scale and network effects in business models 169 in the implementation of business practices. Jari Arkko discussed 170 the impacts of consolidation on the Internet infrastructure in a 171 document for the IETF[6], with the document identifying issues 172 including loss of resilience and increased risk of surveillance. It 173 goes on to note that "it seems prudent to recommend that whenever it 174 comes to Internet infrastructure services, centralised designs 175 should be avoided where possible".[7] From networks to applications, 176 the overarching theme was that consolidation is taking place from 177 one end of the Internet to the other. Additionally, the Journal of 178 Cyber Policy published a special edition on Consolidation of the 179 Internet. Topics in this special issue included market concentration 180 and security, DNS consolidation, supply chains, interoperability and 181 Internet architecture. However, much is still yet to be discussed on 182 consolidation at most layers of the Internet stack. [8] 184 Recently, the US has scrutinized Internet platform services. The 185 release of report Investigation of Competition in Digital Markets in 186 October 2020 [9] showed that both concentration and consolidation in 187 the online marketplace has left consumers with little choice, again 188 at the application layer. Additionally, the US Justice Department 189 announced it is suing Google for Antitrust violations on 20 October 190 2020.[10] Both the report and the lawsuit show that concentration of 191 power of Internet platform services has alarmed the House of 192 Representatives and the Department of Justice to the point of 193 investigation and possible criminal charges. None of this would have 194 happed without consolidation of the application layer. The EU has 195 been investigating the 'gatekeeper' status of big tech. [11] Recent 196 reports reveal that the EU is considering ex ante solutions to the 197 issue of the dominance of certain, large platforms. Such remedies, 198 being discussed in the European Commission to date, include 199 mandatory data sharing and/or mandatory interoperability 200 requirements.[12] Such remedies seek to address the dominant market 201 share of application layer services by American tech companies in 202 Europe. 204 The rhetoric and discussion of consolidation primarily focuses on 205 Internet services and data. However, it is important to draw 206 attention to the issues and risks of consolidation at other layers 207 of the Internet beyond just the application layer. The application 208 layer is directly user facing and, as a result, is what users 209 experience. But the underlying infrastructure and protocols are also 210 going through consolidation as they develop. The complete end to end 211 encryption model forces data into endpoints which consolidates data 212 into and handful of companies. Furthermore, protocol standards are 213 facilitating this consolidation. 215 The QUIC protocol is an example of the consolidation between layers 216 of the Internet - and not at the application layer. Designed and 217 deployed as a transport layer protocol, it effectively replaces TCP 218 at the network layer while also adding improved security. The result 219 is the merging or consolidation of three layers. QUIC should improve 220 efficiency and delivery of applications, but also forces all data to 221 be managed at the endpoint, which in this case is a browser, making 222 it more difficult to manage traffic at the network layer. 224 3. Overarching Issues Related to Consolidation 226 3.1. Technical 228 Consolidation has led to the development of a few, large Internet 229 companies which consumers are using, as mentioned above. But 230 consolidation also has led to the development of a protocols which 231 are developed and used by these few, large Internet companies to 232 control traffic flow and data capture as well. 234 Overarching technical issues related to consolidation include an 235 over-reliance on one or two entities and a handful of protocols. 236 Large stakeholders who have developed and implemented these 237 protocols control the rollout of upgraded versions without 238 competition of even knowledge of it due to the lack of diversity in 239 the market. 241 For example, over 80% of the web browser market is held by two 242 browsers: Chrome and Safari. Chrome alone accounts for 65% of the 243 market overall [13] The makers of Chrome and Safari, Google and 244 Mozilla, have dominated the development of protocols recently and 245 the development QUIC, DoH and TLS. 247 "Did the IETF create a better internet when it approved DoH? There's 248 a lot of disagreement about that, but what has upset many is that 249 DoH was a surprise - the IETF standardised it without consulting 250 some who it was likely to affect," it says in RFC 8890 [14] However, 251 there was little multistakeholder consultation and discussion prior 252 to the adoption of DoH. This was more of a rapid development and 253 deployment process, without the market driving the use cases and 254 uptake. But what did drive the rapid development was the need for 255 Google, with 65% of the browser market, to ensure that the data 256 coming into and onto their services remained there. By forcing the 257 concentration of the data at the endpoint, the data is consolidated 258 into the service provider at that endpoint. Does this make a better 259 internet? 261 3.2. Economic 263 According to the Internet Society's 2019 report Consolidation In the 264 Internet Economy the Internet economy is broadly defined as, 265 "economic activities that either support the Internet or are fundamentally dependent on the Internet's existence."[15] Internet 266 applications, service infrastructure and access provision are the 267 primary three areas of economic activities on the Internet. 269 One focus of consolidation is around the concentration of power - 270 consumer, technical and financial - into a handful of large Internet 271 companies. The first point of engagement with any of these 272 companies, including Facebook and Google, is through consumer 273 applications. The ability to easily understand consolidation at an 274 application layer, because of the widespread and common use of 275 Facebook and Google, has caused the focus of consolidation and anti- 276 competitive issues from policy makers and politicians to be at the 277 application layer. 279 However, consolidation doesn't always have its downsides. 280 Consolidation allows for economies of scale, investment in 281 infrastructure and the ability for small and medium enterprises to 282 buy and use services, like cloud storage, content distribution 283 networks and security technology, without having to build them from 284 the ground up every time. However, the lack of market diversity 285 means a lack of competition which, in turn means a lack of 286 innovation and a lack of consumer choice. 288 Amazon offers affordable cloud services and Cloudflare is one of 289 only a handful of companies that are content delivery networks at a 290 large scale. So large, in fact, that a substantial amount of 291 Internet traffic transits through Cloudflare's servers, though there 292 are many thousands of small CDNs. Rather than each and every 293 Internet application company create their own storage and content 294 delivery network, it is easier and more affordable to outsource both 295 to other companies. Because of the cost of CDNs at scale, few 296 companies offer these services. 298 The market should be a regulating factor in consolidation. New 299 entrants and competition in a market creates options for consumers 300 that potentially pulls them away from popular websites and 301 applications. When a market is not competitive or viable, regulation 302 and anti-trust measures can intervene to remedy a consolidated 303 market which is tending towards or has achieved monopoly status. 304 Legal and regulatory intervention, however, tends to create its own 305 set of issues as seen through several decades of EU intervention in 306 big tech starting with Microsoft in 2004. Unintended consequences 307 with regulatory or legal intervention may skew the market even 308 further. 310 3.3. Security 312 Consolidation of protocol development which has facilitated the 313 secure, end to end encryption of information going over networks in 314 recent years. New technologies such as DNS-over-HTTPS (DoH) and DNS- 315 over-TLS (DoT) standardised through the IETF process allow for 316 confidential look up of DNS queries. However, it has forced updates 317 onto many DNS servers and operating systems. This change in the look 318 up process is forcing the technology to develop in a way which has 319 narrowed the ability for companies and small industries to do DNS 320 look ups without updating out of date hardware and software, thereby 321 disenfranchising developing countries and smaller companies without 322 big budgets. This is a form of market consolidation based on 323 development choices by several large companies. These development 324 choices are often technically opaque without transparency of what 325 happens when updates take place, resulting in more difficulty when 326 trying to troubleshoot security issues. 328 The development of these protocols, while providing increased 329 privacy and addressing issues concerning government surveillance, 330 have forced other unintended consequences which is promoting 331 consolidation. 333 Consequences of the security of the global Internet are evident. On 334 June 8, 2021, a global outage of Fastly, a content delivery network 335 (CDN), was caused by a software update which included an 336 undiscovered bug. [16] While this was resolved within a working day, 337 one of the main causes of the outage was a dependency on the limited 338 number of CDNs running services in the cloud. Other CDNs, which 339 resolved traffic via Fastly for redundancy, were also taken down as 340 a result of the Fastly outage. This dependency is caused by 341 consolidation and a concentration of infrastructure. A highly 342 consolidated CDN network facilitates a less secure environment 343 because of the weakening of resilience [17] 345 4. Implications of Consolidation on Internet Architecture 347 4.1. The Changing Architecture of the Internet 349 The phenomenon of consolidation may be in the eyes of the beholder. 350 A government may see market failure or a need for regulation. [18] A 351 civil society advocate may see it from the point of view of privacy 352 or free speech. For the purposes of this draft we view it from the 353 perspective of the underlying architecture of the public Internet. 355 Consolidation in the Internet's architecture is not a new 356 development. The approach of providing intermediaries to deliver 357 service or content rather than the more traditional end-to-end 358 approach has been in place for more than a decade. However, it is 359 possible to argue that the architecture of the Internet has changed 360 dramatically in the last decade. 362 The architecture of the Internet is always changing. New services, 363 applications and content mean that the market creates new ways to 364 deliver them. Consolidation clearly has economic, social and policy 365 issues, but it is important to understand how consolidation affects 366 the underlying architecture of the Internet. The impact of 367 intermediaries on architecture is often not obvious. 369 The use of intermediaries in the Internet's architecture may include 370 the use of third parties to provide services, applications or 371 content. In the early days of the Web, this was evident when 372 rendering a web page that included content from multiple sources. In 373 today's Internet the intermediaries are not so obvious. 374 Authentication servers, content distribution networks, certificate 375 authorities, malicious content protection and DNS resolution 376 services are all examples of tools provided to the Internet by 377 intermediaries - often without the knowledge or approval of both 378 endpoints. 380 Having intermediaries embedded in the architecture is a different 381 effect from having them embedded in the service structure. The 382 domination by a few companies of the content and application layer 383 is largely an economic effect of scale. On the other hand, there is 384 a prevalent belief that the Internet puts intelligence at the edge. 385 While that may have been true in the past, it is hard to argue that 386 this is a feature of the contemporary Internet. 388 There is a suggestion that the network simply provides for the 389 transport of data. There are almost no network connections like that 390 in today's Internet. A consumer's view of the Internet is limited 391 by unseen intermediaries of many types - some delivering positive 392 services, others not. In either case, a consumer on the Internet 393 seldom makes choices about those intermediaries: they are simply 394 part of the fabric that makes up the Internet. 396 It is into just consolidation from the perspective of a consumer. 397 Almost all important parts of the architecture have been affected by 398 consolidation: DNS resolution, access service, transit provision, 399 content distribution and authorization. Consolidation in these areas 400 has a direct effect on engineering and protocol design. 402 4.2. The End-to-End Principle Redux 404 The end-to-end principle is the idea that reliability and 405 trustworthiness reside at the end nodes of networks rather than in 406 the network itself. In other words, the idea was that the network 407 itself was dumb and intelligence was at the edge or end. However, 408 Internet architecture is evolving in such a way that this principle 409 is changing. 411 Networks and the devices on the networks are acting as access 412 consolidators. While, in the past, the network was a simple 413 transporter of bits, today's networks see intermediaries 414 consolidating both access and the delivery of information (e.g. 415 streaming media). For example, 5G will allow for different services, 416 systems and use cases at a very specific level. Network slicing in 417 5G will concentrate services like video on demand into concentrated 418 - and consolidation - areas on a network. [19] In other words, as 419 specific types of services are relegated to a segregated part of a 420 network, the availability and access of that service is limited to 421 accessing a specific network. Depending on the type of device or 422 maturity of the network infrastructure available at the point of the 423 attempted access, options for access might be limited. If a network 424 slice on 5G is where a specific service is located, for example, but 425 it is only possible to use a 3G mobile network, then the service is 426 unavailable. Thus, the service is only available on a consolidated 427 part of the mobile network. 429 Another change is how the layers of the Internet, as discussed in 430 the QUIC example, are consolidating. Differentiation among layers is 431 fading fast with the development of applications which require 432 network access and control. 434 Rapidly, the end-to-end principle is becoming the edge-to-edge 435 principle. The layers of the internet are morphing into several 436 consolidated layers and it is becoming difficult to differentiate 437 between the end or edge, and also nearly impossible to ensure the 438 reliability of the internet because of it. But the important part of 439 this is the network is not dumb. Data processing, storage and highly 440 evolved services (including custom data and metadata processing at 441 the edge) means that the 'dumb' network is no longer dumb. 443 If the number of organizations that provide those "network services" 444 that we rely upon is small, our dependence is higher. In extreme 445 cases of engineering, we put ourselves at risk of engineering a 446 single point of failure. But also if organisations can't and won't 447 enter the market, the market is left with very few options and 448 choices. If the number of organizations that provide those "network 449 services" that we rely upon is small, our dependence is higher. In 450 extreme cases of engineering, we put ourselves at risk of 451 engineering a single point of failure. 453 The trend toward highly specific and concentrated processing, as 454 well as the drive for highly customised applications and services 455 will drive the Internet away from an end-to-end principle. This will 456 create not a network of networks, but a mesh. If the mesh is 457 dependent on a small number of very large providers through 458 consolidation, we will have engineered a single source of failure 459 into the Internet. 461 5. Implications of Consolidation on Protocol Design 463 5.1. Does Protocol Design Really Affect Consolidation? 465 There is an idealized view of collaborative, multistakeholder 466 approaches to Internet protocol development that it is democratic 467 with all parties thinking about the greater good, like in the IETF. 468 In reality, protocol development and standards are subject to vested 469 interests, personal approaches and commercial realities.[20] 470 Developing protocols, and standards more generally, takes time, much 471 discussion and a bottom up approach. However, commercial 472 organisations have different goals in the process of trying to 473 standardize protocols. Larger organisations have more resources 474 dedicated to protocol and standards development. Larger 475 organisations with staff specifically dedicated to standards tend to 476 have the ability to push for their proposals and their protocols. 477 There is no coincidence that these companies are the ones that have 478 facilitated consolidation on a commercial level and are facilitating 479 consolidation on a protocol level. 481 5.2. Case Studies in Consolidation and Protocol Design 483 5.2.1. DNS over HTTPS (DOH) 485 The development of encrypted DNS, specifically DNS-over-HTTPS (DoH), 486 has been driven by a desire to show full end-to-end encryption of 487 network connections. The protocol was completed and the DoH working groupwound up in March 2020 despite the absence of both resolver 488 discovery and selection mechanisms. This may be addressed in the 489 future.[21] 490 Client software is developing with interim discovery solutions which 491 almost always favour the large, cloud-based resolver operators. 492 This is leading to a situation where users are being presented with 493 a very small number of pre-configured resolver options irrespective 494 of their location - in some client software as few as three or four 495 options may be presented. [22] Currently, there are many thousands 496 of servers operating without DoH. 497 It is likely that most of the DNS traffic will be consolidated onto 498 a handful of global operators, if multiple options for discovery 499 mechanisms are not developed. The impact that such a loss of 500 diversity of providers may have on the long-term resilience of DNS 501 should not be underestimated. [23] Nor should the attractiveness of 502 these potential network chokepoints to attack be overlooked either 503 to access consolidated data or launch an attack from. 505 One danger is that if DNS traffic is concentrated onto a small 506 handful of global operators and turned 'automatically-on' the result 507 would be default adoption by the vast majority of the Internet's 508 clients. The suggestion that there were mechanisms for users to 509 opt-out would not matter in the face of statistics that regularly 510 show that users almost never change default settings. Currently, the 511 deployment approach for DoH is opt-in. For CDNs, DoH default-on 512 would disrupt and render CDN geolocation designed to manage traffic 513 flows more efficient closer to the desired delivery location. Thus, 514 protocol design decisions that are enshrined in default settings 515 will become the norm. In this case, default on, which facilitates 516 consolidation, will become standard. 518 By routing the DNS over HTTPS, it becomes much easier to track user 519 activity through the use of cookies. Therefore a protocol that was 520 developed to enhance user privacy and security could actually 521 undermine both: privacy through the use of cookies and security by 522 consolidating DNS traffic onto far fewer resolver operators that are 523 far more attractive targets for malicious actors of various types. 524 5.2.2. Encrypted Server Name Indication (eSNI) 526 Options to encrypt the Server Name Indication (SNI) have been 527 explored in the TLS working group but to date it has not been 528 possible to develop a solution without shortcomings. This flaw in 529 the encrypted SNI (eSNI) options under evaluation required a rethink 530 in the approach being taken. 531 The solution now proposed, Encrypted Client Hello (ECH, previously 532 called ECHO) assumes that private origins will co-locate with or 533 hide behind a provider (CDN, application server etc.) which can 534 protect SNIs for all of the domains that it hosts.[24] Whilst there 535 is logic in this approach, the consequence is that the would-be 536 standard encourages further consolidation of data to aid privacy. 537 What it does not appear to consider is the attractiveness of this 538 larger data pool to an attacker, compared with more dispersed 539 solutions. 540 5.2.3. Privacy Pass 542 The Privacy Pass protocol provides a set of cross-domain 543 authorization tokens that protect the client's anonymity in message 544 exchanges with a server. This allows clients to communicate an 545 attestation of a previously authenticated server action, without 546 having to reauthenticate manually. The tokens retain anonymity in 547 the sense that the act of revealing them cannot be linked back to 548 the session where they were initially issued. 550 For Privacy Pass to succeed clients must be able to acquire tokens 551 that they can later redeem with greater privacy and anonymity. This 552 document does not discuss the goals of privacy or anonymity. 553 Instead, it identifies a problem related to the upper bound in 554 number of servers that affects the Privacy Pass ecosystem. 556 "Server centralization" is the strict limit or upper bound in the 557 number of servers available from which a client can acquire a token 558 for later redemption. 560 The architecture draft for Privacy Pass specifies an upper limit of 561 four for this upper bound. Four is a small number through which to 562 run authorizations. There is little room for mistakes or redundancy. 564 An upper bound to available Privacy Pass servers creates 565 architectural, engineering and practical problems for the deployment 566 of the protocol. Any successful deployment of Privacy Pass must find 567 mitigations for these problems. 569 6 Potential Technical Risks 571 There are a number of potential risks to the security, stability and 572 performance of the Internet and many of them are well articulated in 573 draft-livingood-doh-implementation-risks-issues-04, but some notable 574 ones are: 575 1. Significant operational shift of the global Internet from a 576 highly distributed to a centralised system. This would 577 impact both security and resilience. 578 2. Decreased stability due to the fact that a centralised 579 system will have higher fragility, fewer points of failure 580 and greater impact on the system when it does fail. 581 3. Increased security issues caused by the reduction of number 582 of recursive DNS operators. [see 583 https://hbswk.hbs.edu/item/evidence-of-decreasing-internet- 584 entropy-the-lack-of-redundancy-in-dns-resolution-by-major- 585 websites-and-services] Lack of distributed and recursive 586 DNS creates a lack of redundancy for when security attacks 587 hit parts of the Internet. 588 4. Loss of security threat visibility due to degraded ability 589 to use DNS blocklists and overall network management for 590 malware, phishing, spam, DDoS and etc if DNS management is 591 consolidated into a few operators. 593 5. Reduced diversity in the Internet ecosystem. Diversity 594 creates greater redundancy, resilience and agility to 595 respond to attacks, outages and network issues. 597 6. Actions for the IETF, IRTF and IAB 599 This document proposes a set of concrete actions: 601 1] using MAPRG in the IRTF to attempt to establish metrics for 602 consolidation. The goal would be to attempt to gain consensus on 603 measurements for consolidation and a mechanism for gathering those 604 metrics over time to answer the question of how much and how quickly 605 the Internet is consolidating. 607 2] encouraging the consideration of consolidation in protocol design 608 either through the requirement of a new section in RFCs that 609 addresses consolidation or thorough guidance to area director 610 reviews of documents in IETF Last Call. 612 3] a new IAB workshop on the Implications of Consolidation on 613 Protocol Design with the goal of encouraging position papers from a 614 variety of stakeholders in the protocol design and implementation 615 process. 617 4] potentially expanding the human rights review process for 618 protocols to include examination of individual protocol design on 619 markets, enterprises and society. 621 5]attract and retain the participation of operators and implementors 622 who may be impacted. 624 6]ensure detailed community assessment of risks and issues. In 625 particular, assess the following issues: 627 . What is the threat model that makes this technical change 628 justifiable? 629 . What are the security and privacy implications? 630 . What are the implications for stability, operations, network 631 and systems administration, software development, diversity 632 and etc? 633 . Do the benefits outweigh any drawbacks? 634 . What alternatives to the changes could be made? 636 7. Security Considerations 638 While this document does not describe a specific protocol, it does 639 discuss the evolving architecture of the Internet. Changes to the 640 Internet's architecture have direct and indirect implications for 641 the Internet's threat model. In another draft [25], we discuss how 642 the evolution of the Internet has changed the threat model. 643 Specifically, the changes to the end-to-end model (see section 4.2 644 above) have inserted new interfaces which must be reflected in 645 security considerations for new protocols. 647 8. IANA Considerations 649 This memo contains no instructions or requests for IANA. The authors 650 continue to appreciate the efforts of IANA staff in support of the 651 IETF. 653 9. Conclusions 655 This document seeks to rekindle and restart the discussion on 656 consolidation. As argued above, Internet consolidation is happening 657 at different places and different layers of the Internet. Though 658 there has been interest in the Internet consolidation in the past, 659 now is the time to start the discussions again. 661 10. References 663 10.1. Informative References 665 [1] Considerations on Internet Consolidation and the Internet 666 Architecture [draft-arkko-iab-internet-consolidation-02]. 668 [2] IBID 670 [3] Google has over at least 80% worldwide market share. 671 https://www.statista.com/statistics/216573/worldwide-market- 672 share-of-search-engines/ 674 [4] Investigation of Competition in Digital Markets, Subcommittee 675 on Antitrust, Commercial and Administrative Law of the 676 Committee on the Judiciary, United States House of 677 Representatives, 6 October 2020. 679 [5] Following An Unexpected Rebound In M&A, Businesses Are Banking 680 On A New Kind Of Dealmaking For Growth In A Post-Covid World 681 https://www.prnewswire.com/news-releases/following-an- 682 unexpected-rebound-in-ma-businesses-are-banking-on-a-new-kind- 683 of-dealmaking-for-growth-in-a-post-covid-world-301228786.html 685 [6] Design Expectations vs. Deployment Reality in Protocol 686 Development Workshop 2019, Intern Architecture Board 687 https://www.iab.org/activities/workshops/dedr- 688 workshop/position-papers/ 690 [7] Centralised Architecture in Internet Infrastructure [draft- 691 arkko-arch-infrastructure-centralisation-00]. 693 [8] IBID page 5. 695 [9] Journal of Cyber Policy, Volume 5, Issue 1 (2020) Special 696 Issue: Consolidation of the Internet 697 (https://www.tandfonline.com/toc/rcyb20/5/1) 699 [10] Investigation of Competition in Digital Markets, Subcommittee 700 on Antitrust, Commercial and Administrative Law of the 701 Committee on the Judiciary, United States House of 702 Representatives, 6 October 2020. 704 [11] Statement of the Attorney General on the Announcement Of Civil 705 Antitrust Lawsuit Filed Against Google, United States 706 Department of Justice, 20 October 2020. 707 https://www.justice.gov/opa/pr/statement-attorney-general- 708 announcement-civil-antitrust-lawsuit-filed-against-google 710 [12] Digital Services Act package, European Commission, ongoing 711 https://ec.europa.eu/info/law/better-regulation/have-your- 712 say/initiatives/12418-Digital-Services-Act-package-ex-ante- 713 regulatory-instrument-of-very-large-online-platforms-acting- 714 as-gatekeepers 716 [13] Browser & Platform Market Share January 2021 717 https://www.w3counter.com/globalstats.php 719 [14] RFC 8890, The Internet is for End Users. Nottingham, Mark. 720 August 2020. https://www.rfc-editor.org/info/rfc8890 722 [15] Consolidation In the Internet Economy, Internet Society, 2019. 723 https://future.internetsociety.org/2019/consolidation-in-the- 724 internet-economy 726 [16] Fastly Blog, June 8, 2021. 727 https://www.fastly.com/blog/summary-of-june-8-outage 729 [17] The Deeper Root Cause of the Fastly and Akamai Outages, 730 CircleID, June 28, 2021 731 https://www.circleid.com/posts/20210628-the-deeper-root-cause- 732 of-the-fastly-and-akamai-outages/ 734 [18] See Google, antitrust and how to best regulate big tech, The 735 Economist, 7 October 2020 736 https://www.economist.com/business/2020/10/07/google- 737 antitrust-and-how-best-to-regulate-big-tech 739 [19] What is Network Slicing? https://5g.co.uk/guides/what-is- 740 network-slicing/ 742 [20] Dominique Lazanski, Governance in international technical 743 standards-making: a tripartite model, Journal of Cyber 744 Policy, 4:3, 362-379, 2019. 745 https://www.tandfonline.com/doi/full/10.1080/23738871.2019.169 746 6851 748 [21] DNS over HTTPS (doh) 749 https://datatracker.ietf.org/group/doh/about/ 751 [22] At the time of writing, the Firefox browser presents a list of 752 three pre-configured resolver options to North American users: 753 Cloudflare, NextDNS and Comcast. 755 [23] Cloudflare DNS goes down taking a large piece of the Internet 756 with it, 17 July 2020. 757 https://techcrunch.com/2020/07/17/cloudflare-dns-goes-down- 758 taking-a-large-piece-of-the-internet-with-it/ 760 [24] TLS Encrypted Client Hello draft-ietf-tls-esni-07 761 https://tools.ietf.org/html/draft-ietf-tls-esni-07 763 [25] An Internet for Users Again draft-lazanski-smart-users- 764 internet-00 https://tools.ietf.org/html/draft-lazanski-smart- 765 users-internet-00 767 11. Acknowledgments 769 Many thanks to all who discussed this with us, especially Jason 770 Livingood. 772 This document was prepared using 2-Word-v2.0.template.dot. 774 Authors' Addresses 776 Dominique Lazanski 777 Last Press Label 778 London, UK 780 Email: dml@lastpresslabel.com 782 Mark McFadden 783 Internet policy advisors ltd 784 Chepstow, Wales, UK 786 Email: mark@internetpolicyadvisors.com 788 Eliot Lear 789 Cisco Systems (Switzerland) GmbH 790 Richtistrasse 7 791 CH-8304 Wallisellen 792 Switzerland 794 Email: lear@cisco.com