idnits 2.17.00 (12 Aug 2021) /tmp/idnits39183/draft-nottingham-avoiding-internet-centralization-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 : ---------------------------------------------------------------------------- ** 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 document date (9 February 2022) is 94 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'SCALE-FREE' is defined on line 934, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-10 == Outdated reference: A later version (-03) exists of draft-thomson-tmi-02 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft 9 February 2022 4 Intended status: Informational 5 Expires: 13 August 2022 7 Centralization and Internet Standards 8 draft-nottingham-avoiding-internet-centralization-02 10 Abstract 12 Despite being designed and operated as a decentralized network-of- 13 networks, the Internet is continuously subjected to forces that 14 encourage centralization. 16 This document offers a definition of centralization, explains why it 17 is undesirable, identifies different types of centralization, 18 catalogues limitations of common approaches to controlling it, and 19 explores what Internet standards efforts can do to address it. 21 About This Document 23 This note is to be removed before publishing as an RFC. 25 Status information for this document may be found at 26 https://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet- 27 centralization/. 29 Source for this draft and an issue tracker can be found at 30 https://github.com/mnot/avoiding-internet-centralization. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 13 August 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. What is Centralization . . . . . . . . . . . . . . . . . . . 3 67 3. Why Avoid Centralization . . . . . . . . . . . . . . . . . . 5 68 4. Kinds of Centralization . . . . . . . . . . . . . . . . . . . 6 69 4.1. Direct Centralization . . . . . . . . . . . . . . . . . . 6 70 4.2. Necessary Centralization . . . . . . . . . . . . . . . . 7 71 4.3. Indirect Centralization . . . . . . . . . . . . . . . . . 8 72 4.4. Inherited Centralization . . . . . . . . . . . . . . . . 8 73 4.5. Platform Centralization . . . . . . . . . . . . . . . . . 9 74 5. The Limits of Decentralization . . . . . . . . . . . . . . . 10 75 5.1. Federation isn't Enough . . . . . . . . . . . . . . . . . 10 76 5.2. Multi-Stakeholder Administration is Hard . . . . . . . . 11 77 5.3. Blockchains Are Not Magical . . . . . . . . . . . . . . . 12 78 6. What Should Internet Standards Do? . . . . . . . . . . . . . 14 79 6.1. Be Realistic . . . . . . . . . . . . . . . . . . . . . . 14 80 6.2. Decentralize Proprietary Functions . . . . . . . . . . . 15 81 6.3. Build Well-Balanced Standards . . . . . . . . . . . . . . 15 82 6.4. Limit Intermediary Power . . . . . . . . . . . . . . . . 16 83 6.5. Avoid Over-Extensibility . . . . . . . . . . . . . . . . 18 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 8. Informative References . . . . . . . . . . . . . . . . . . . 18 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 21 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 The Internet has succeeded in no small part because of its purposeful 92 avoidance of any single controlling entity. While this approach may 93 reflect a desire to prevent a single technical failure from having 94 wide impact [RAND]. it has also enabled the Internet's rapid adoption 95 and broad spread, because internetworking did not require networks to 96 get permission from or cede control to another entity -- thereby 97 accommodating a spectrum of requirements and positioning the Internet 98 as a public good. 100 While avoiding centralization is a widely shared goal for the 101 Internet, achieving it has proven difficult. Many successful 102 protocols and applications on the Internet today work in a 103 centralized fashion -- to the point where some proprietary, 104 centralized services have become so well-known that they are commonly 105 mistaken for the Internet itself. Even when protocols incorporate 106 techniques intended to prevent centralization, economic and social 107 factors can drive users to prefer centralized solutions built with or 108 on top of supposedly decentralized technology. 110 These difficulties call into question what role architectural 111 regulation -- in particular, open standards bodies such as the IETF 112 -- should play in preventing, mitigating, and controlling Internet 113 centralization. 115 This document discusses aspects of centralization that relate to 116 Internet standards efforts. Section 2 provides a definition of 117 centralization. Section 3 explains why centralization of the 118 Internet's functions is undesirable. Section 4 surveys the different 119 kinds of centralization that might surface on the Internet. 120 Section 5 then catalogues high-level approaches to mitigating 121 centralization and discusses their limitations. Finally, Section 6 122 considers the role that Internet standards play in avoiding 123 centralization and mitigating its effects. 125 Engineers who design and standardize Internet protocols are the 126 primary audience for this document. However, designers of 127 proprietary protocols can benefit from considering aspects of 128 centralization, especially if they intend their protocol to be 129 considered for eventual standardisation. Likewise, policymakers can 130 use this document to help identify and remedy inappropriately 131 centralized protocols and applications. 133 2. What is Centralization 135 This document defines "centralization" as the ability of a single 136 entity (e.g., a person, company, or government) -- or a small group 137 of them -- to exclusively observe, capture, control, or extract rent 138 from the operation or use of a Internet function. 140 Here, "Internet function" is defined broadly. It might be an 141 enabling protocol already defined by standards, such as IP [RFC791], 142 BGP [RFC4271], TCP [RFC793], or HTTP [HTTP]. It might also be a 143 proposal for a new enabling protocol, or an extension to an existing 144 one. 146 However, the Internet's functions are not limited to standards- 147 defined protocols. User-visible applications built on top of 148 standard protocols are also vulnerable to centralization -- for 149 example, social networking, file sharing, financial services, and 150 news dissemination. Likewise, the supply of underlying networking 151 equipment, hardware, operating systems, and software can exhibit 152 centralization that affects the Internet. 154 Centralization risk is strongest when it affects the entire Internet. 155 However, it can also be present when a substantial portion of the 156 Internet's users lack options for a function. For example, if there 157 is only one provider for a function in a region or legal 158 jurisdiction, that function is effectively centralized for those 159 users. 161 "Decentralization" is the process of identifying centralization risk 162 in the functions of a protocol or application, followed by the 163 application of techniques used to prevent or mitigate centralization. 165 Decentralization does not require that a function need be so widely 166 distributed that other important factors are sacrificed. Because the 167 same network effects that cause centralization can also deliver 168 benefits (such as improvements in efficiency, resiliency, latency, 169 and availability; see Section 6.4 for further discussion), the 170 appropriate amount of decentralization for a function might vary, 171 with the optimal balance being determined by many factors. A 172 function that is only available through a relatively small number of 173 providers can still be effectively decentralized (see, for example, 174 the Domain Name System [RFC1035]). 176 Therefore, discussions of centralization and architectural efforts at 177 decentralization need to be made on a case-by-base basis, depending 178 on the function in question, surrounding circumstances, and other 179 regulatory mechanisms. 181 Note that it is important to distinguish centralization from anti- 182 competitive concerns (also known as "anti-trust"). While there are 183 many interactions between them and making the Internet more 184 competitive may be a motivation for avoiding centralization, only 185 courts are authoritative in determining what is and is not anti- 186 competitive in a defined market, not standards bodies and other 187 technical fora. 189 3. Why Avoid Centralization 191 Centralization is undesirable because it is counter to the Internet's 192 nature, because it violates the end users' expectations, and because 193 of the many negative effects it can have on the network's operation 194 and evolution. 196 First, the Internet's very nature is incompatible with centralization 197 of its functions. As a "large, heterogeneous collection of 198 interconnected systems" [BCP95] the Internet is often characterised 199 as a "network of networks". These networks relate as peers who agree 200 to facilitate communication, rather than having a relationship of 201 subservience to others' requirements or coercion by them. This focus 202 on independence of action carries through the way the network is 203 architected -- for example, in the concept of an "autonomous system". 205 Second, as the Internet's first duty is to the end user [RFC8890], 206 allowing such power to be concentrated into few hands is counter to 207 the IETF's mission of creating an Internet that "will help us to 208 build a better human society." [BCP95] When a third party has 209 unavoidable access to communications, the "informational and 210 positional advantages" [INTERMEDIARY-INFLUENCE] gained can be used to 211 observe behavior (the "panopticon effect") and shape or even deny 212 behaviour (the "chokepoint effect") -- which can be used by those 213 parties (or the states that have authority over them) for coercive 214 ends. [WEAPONIZED-INTERDEPENDENCE] 216 Finally, concentration of power has deleterious effects on the 217 Internet itself, including: 219 * _Limiting Innovation_: Centralization can preclude the possibility 220 of "permissionless innovation" -- the ability to deploy new, 221 unforeseen applications without requiring coordination with 222 parties other than those you are communicating with. 224 * _Constraining Competition_: The Internet and its users benefit 225 from robust competition when applications and services are 226 available from many providers -- especially when those users can 227 build their own applications and services based upon interoperable 228 standards. When functions form dependencies on a centralized 229 service or platform because no substitutes are suitable, it 230 effectively becomes an essential facility, which encourages abuse 231 of power. 233 * _Reducing Availability_: The Internet's availability (as well as 234 applications and services built upon it) improves when there are 235 many ways to obtain access to it. While centralized services 236 typically benefit from the focused attention that their elevated 237 role requires, when they fail, the resulting loss of availability 238 can have a disproportionate impact. 240 * _Creating Monoculture_: The scale available to a centralized 241 service or application can magnify minor flaws in features such as 242 recommendation algorithms to a degree that can have broad (even 243 societal) consequences. Diversity in these functions' 244 implementation is significantly more robust when viewed 245 systemically. [POLYCENTRIC] 247 * _Self-Reinforcement_: As widely noted (see, e.g., [ACCESS]), a 248 centralized service's access to data allows it the opportunity to 249 make improvements to its offerings, while denying such access to 250 others. 252 See also [TECH-SUCCESS-FACTORS] for further exploration of how 253 centralization can affect the Internet. 255 To summarize, centralization would allow the Internet (or some part 256 of it) to be captured, effectively turning it into a "walled garden" 257 that cannot meet both architectural design goals and users' 258 expectations, and endangering its ongoing viability at the same time. 260 4. Kinds of Centralization 262 Centralization of the Internet is not uniform; it presents in a 263 variety of ways, depending on its relationship to the function in 264 question and underlying causes. The subsections below suggest a 265 classification system for Internet centralization. 267 4.1. Direct Centralization 269 Creation of a fixed role for a specific party is the most 270 straightforward kind of centralization. For example, most 271 proprietary messaging, videoconferencing, chat, and similar protocols 272 operate in this fashion. 274 While some argue that such protocols are simpler to design, more 275 amenable to evolution, and more likely to meet user needs [MOXIE], 276 this approach most often reflects commercial goals -- in particular, 277 a strong desire to capture the protocols' financial benefits by 278 "locking in" users to a proprietary service. 280 Directly centralised protocols and applications are not considered to 281 be part of the Internet per se; instead, they are more properly 282 characterized as proprietary protocols that are built on top of the 283 Internet. As such, the Internet architecture and associated 284 standards do not regulate them, beyond the constraints that the 285 underlying protocols (e.g., TCP, IP, HTTP) impose. 287 4.2. Necessary Centralization 289 Some protocols introduce centralization risk that is unavoidable by 290 nature. 292 For example, when there is a need for a single, globally coordinated 293 "source of truth", that function is by nature centralized -- such as 294 in the Domain Name System (DNS), which allows human-friendly naming 295 to be converted into network addresses in a globally consistent 296 fashion. 298 IP addresses allocation is another example of a necessary function 299 having centralization risk. Internet routing requires addresses to 300 be allocated uniquely, but if a single government or company captured 301 the addressing function, the entire Internet would be at risk of 302 abuse by that entity. 304 Similarly, the need for coordination in the Web's trust model brings 305 centralization risk, because of the Certificate Authority's role in 306 communication between clients and servers. 308 Protocols that need to solve the "rendezvous problem" to coordinate 309 communication between two parties that are not in direct contact also 310 suffer from this kind of centralization risk. For example, chat 311 protocols need to coordinate communication between two parties that 312 wish to talk; while the actual communication can be direct between 313 them (so long as the protocol facilitates that), the endpoints' 314 mutual discovery typically requires a third party. 316 Internet protocols often attempt to mitigate necessary centralization 317 risk using measures such as federation (see Section 5.1) and multi- 318 stakeholder administration (see Section 5.2). 320 Protocols that successfully mitigate necessary centralization are 321 often reused, to avoid the considerable cost and risk of re- 322 implementing those mitigations. For example, if a protocol requires 323 a coordinated, global naming function, reusing the Domain Name System 324 is usually preferable to establishing a new system. 326 4.3. Indirect Centralization 328 Even when a protocol avoids direct centralization and does not 329 exhibit any necessary centralization, it might become centralized in 330 practice when external factors influence its deployment. Factors 331 that encourage use of a central function, despite the absence of such 332 a requirement in the protocol itself, can cause indirect 333 centralization. Such factors might be economic, social, or legal. 335 Often, the factors driving indirect centralization are related to the 336 network effects that are so often seen on the Internet. While in 337 theory every node on the Internet is equal, in practice some nodes 338 are much more connected than others: for example, just a few sites 339 drive much of the traffic on the Web. While expected and observed in 340 many kinds of networks,[SCALE-FREE] network effects award asymmetric 341 power to nodes that act as intermediaries to communication. 343 Left unchecked, these factors can cause a potentially decentralized 344 application to become directly centralised, because the central 345 function has leverage to "lock in" users. For example, social 346 networking is an application that is currently supplied by a few 347 directly centralized, proprietary platforms despite standardization 348 efforts (see, e.g., [W3C.CR-activitystreams-core-20161215]), because 349 of the powerful network effects associated. 351 By its nature, indirect centralization is difficult to avoid in 352 protocol design, and federated protocols are particularly vulnerable 353 to it (see Section 5.1). 355 4.4. Inherited Centralization 357 Most Internet protocols and applications depend on other, "lower- 358 layer" protocols. The features, deployment, and operation of these 359 dependencies can surface centralization risk into functions and 360 applications build "on top" of them. 362 For example, the network between endpoints can introduce 363 centralization risk to application-layer protocols, because it is 364 necessary for communication and therefore has power over it. A 365 network might block access to, slow down, or change the content of 366 various application protocols or specific services for financial, 367 political, operational, or criminal reasons, thereby creating 368 pressure to use other services, which can result in centralization of 369 them. 371 Inherited centralization risk is only present when users cannot use 372 an alternative means of accessing the desired service. For example, 373 users often have flexibility in choice of Internet access, so they 374 could just "route around" a network that affects their chosen 375 service. However, such choices are often not available at the 376 moment, and the Internet's topology means that a choke point upstream 377 could still affect their Internet access. 379 When deployed at scale, encryption can be an effective technique to 380 control many inherited centralization risks. By reducing the number 381 of parties who have access to content of communication, the ability 382 of lower-layer protocols and intermediaries at those layers to 383 interfere with or observe is prevented. Even while they may still 384 prevent communication, encryption makes it more difficult to 385 discriminate the target from other traffic. 387 Note that the prohibitive effect on inherited centralization is most 388 pronounced when most (if not all) traffic is encrypted -- providing 389 yet more motivation for that goal (see also [RFC7258]). 391 4.5. Platform Centralization 393 The complement to inherited centralization is platform centralization 394 -- where a function does not directly define a central role, but 395 could facilitate centralization in the applications it supports. 397 For example, HTTP [HTTP] is not considered a centralized protocol; 398 interoperable servers are relatively easy to instantiate, and 399 multiple clients are available. It can be used without central 400 coordination beyond that provided by DNS, as discussed above. 402 However, applications built on top of HTTP (as well as the rest of 403 the "Web Platform") often exhibit centralization. As such, HTTP is 404 an example of a platform for centralization -- while the protocol 405 itself is not centralized, it facilitates the creation of centralized 406 services and applications. 408 Like indirect centralization, platform centralization is difficult to 409 prevent with protocol design. Because of the layered nature of the 410 Internet, most protocols allow considerable flexibility in how they 411 are used, often in a way that it becomes attractive to form a 412 dependency on one party's operation. Notably, this can happen even 413 if the protocol does not accommodate intermediation explicitly. 415 5. The Limits of Decentralization 417 Over time, various techniques have been developed to decentralize 418 protocols and applications. While use of these approaches can result 419 in a function which is less centralized or less amenable to some 420 kinds of centralization, they are not adequate to avoid 421 centralization completely. They are also not indicators of whether a 422 protocol is centralized without further analysis. 424 5.1. Federation isn't Enough 426 A widely known technique for managing centralization in Internet 427 protocols is federation -- designing them in such a way that new 428 instances of any intermediary or otherwise centralized function are 429 relatively easy to create, and they can maintain interoperability and 430 connectivity with other instances. 432 For example, SMTP [RFC5321] is the basis of the e-mail suite of 433 protocols, which has two functions that are necessarily centralized: 435 1. Giving each user a globally unique address, and 437 2. Routing messages to the user, even when they change network 438 locations or are disconnected for long periods of time. 440 E-mail reuses DNS to help mitigate the first risk. To mitigate the 441 second, it defines an intermediary role for routing users' messages, 442 the Message Transfer Agent (MTA). By allowing anyone to deploy an 443 MTA and defining rules for interconnecting them, the protocol's users 444 avoid a requirement for a single central router. 446 Users can (and often do) choose to delegate that role to someone 447 else, or run their own MTA. However, running your own mail server 448 has become difficult, because of the likelihood of a small MTA being 449 classified as a spam source. Because large MTA operators are widely 450 known and have greater impact if their operation is affected, they 451 are less likely to be classified as such, indirectly centralizing the 452 protocol's operation (see Section 4.3). 454 Another example of a federated Internet protocol is XMPP [RFC6120], 455 supporting "instant messaging" and similar functionality. Like 456 e-mail, it reuses DNS for naming and requires federation to 457 facilitate rendezvous of users from different systems. 459 While some deployments of XMPP do support truly federated messaging 460 (i.e., a person using service A can interoperably chat with someone 461 using service B), many of the largest do not. Because federation is 462 voluntary, some operators captured their users into a single service, 463 rather than provide the benefits of global interoperability. 465 The examples above illustrate that federation can be a useful 466 technique to avoid direct centralization and manage necessary 467 centralization, but on its own does not avoid indirect and platform 468 centralization. If a single entity can capture the value provided by 469 a protocol, they may use the protocol as a platform to get a "winner 470 take all" outcome -- a significant risk with many Internet protocols, 471 since network effects often promote such outcomes. Likewise, 472 external factors (such as spam control) might naturally "tilt the 473 table" towards a few operators. 475 5.2. Multi-Stakeholder Administration is Hard 477 The risks associated with a necessarily centralized function (see 478 Section 4.2) are sometimes mitigated by delegating that function's 479 administration to a multi-stakeholder body. 481 A multi-stakeholder body is an institution that includes 482 representatives of the different kinds of parties that are affected 483 by the system's operation ("stakeholders") in an attempt to make 484 well-reasoned, broadly agreed-to, and authoritative decisions. 486 The most relevant example of this technique is the administration of 487 the DNS, which as a "single source of truth" exhibits necessary 488 centralization in its naming function, as well as the operation of 489 the system overall. To mitigate operational centralization, multiple 490 root servers that are administered by separate operators (themselves 491 diverse in geography) and a selection of corporate entities, non- 492 profits, and government bodies from many jurisdictions and 493 affiliations carry this task out. The name space itself is regulated 494 by the Internet Corporation for Assigned Names and Numbers (ICANN) 495 (https://www.icann.org/resources/pages/governance/governance-en), 496 which is defined as a globally multi-stakeholder body with 497 representation from end users, governments, operators, and others. 499 Another example of multi-stakeholderism is the standardization of 500 Internet protocols themselves. Because a specification effectively 501 controls implementation behavior, the standardization process can be 502 seen as a single point of control. As a result, Internet standards 503 bodies like the IETF allow open participation and contribution, make 504 decisions in an open and accountable way, have a well-defined process 505 for making (and when necessary, appealing) decisions, considering the 506 views of different stakeholder groups [RFC8890]. 508 Yet another example is the administration of the Web's trust model, 509 implemented by Web browsers as relying parties and Certificate 510 Authorities as trust anchors. To assure that all parties meet the 511 operational and security requirements necessary to provide the 512 desired properties, the CA/Browser Forum (https://cabforum.org) was 513 established as an oversight body that involves both of those parties 514 as stakeholders. 516 A major downside of this approach is that setup and ongoing operation 517 of multi-stakeholder bodies is not trivial. Additionally, their 518 legitimacy cannot be assumed, and may be difficult to establish and 519 maintain (see, e.g., [LEGITIMACY-MULTI]). This concern is especially 520 relevant if the function being coordinated is broad, complex, and/or 521 contentious. 523 5.3. Blockchains Are Not Magical 525 Increasingly, distributed consensus technologies, such as the 526 blockchain, are touted as a solution to centralization issues. A 527 complete survey of this rapidly changing area is beyond the scope of 528 this document, but at a high level, we can generalise about their 529 properties. 531 These techniques attempt to avoid centralization risk by distributing 532 intermediary or otherwise potentially centralized functions to 533 members of a large pool of protocol participants. Proper performance 534 of a function is typically guaranteed using cryptographic techniques 535 (often, an append-only transaction ledger). A particular task's 536 assignment to a node for handling usually cannot be predicted or 537 controlled. 539 Sybil attacks (where enough participants coordinate their activity to 540 affect the protocol's operation) are a major concern for these 541 protocols. Diversity in the pool of participants is encouraged using 542 indirect techniques such as proof-of-work (where each participant has 543 to demonstrate significant consumption of resources) or proof-of- 544 stake (where each participant has some other incentive to execute 545 correctly). 547 Use of these techniques can create barriers to direct and inherited 548 centralization. However, depending upon the application in question, 549 indirect and platform centralization can still be possible. 551 Furthermore, distributed consensus technologies have several 552 potential shortcomings that may make them inappropriate -- or at 553 least difficult to use -- for many Internet applications, because 554 their use conflicts with other important goals: 556 1. Distributed consensus has significant implications for privacy. 557 Because activity (such as queries or transactions) are shared 558 with many unknown parties (and often publicly visible due to the 559 nature of the blockchain) they have very different privacy 560 properties than traditional client/server protocols. Potential 561 mitigations (e.g., Private Information Retrieval; see, e.g., 562 [PIR]) are still not suitable for broad deployment. 564 2. Their complexity and "chattiness" typically result in 565 significantly less efficient use of the network (often, to 566 several orders of magnitude). When distributed consensus 567 protocols use proof-of-work, energy consumption can become 568 significant (to the point where some jurisdictions have banned 569 its use). 571 3. Distributed consensus protocols are still not proven to scale to 572 the degree expected of successful Internet protocols. In 573 particular, relying on unknown third parties to deliver 574 functionality can introduce variability in latency, availability, 575 and throughput. This is a marked change for applications with 576 high expectations for these properties (e.g., commercial Web 577 services). 579 4. By design, distributed consensus protocols diffuse responsibility 580 for a function among several difficult-to-identify parties. 581 While this may be an effective way to prevent some kinds of 582 centralization, it also means that making someone accountable for 583 how the function is performed is impossible, beyond the bounds of 584 the protocol's design. 586 It is also important to recognise that a protocol or an application 587 can use distributed consensus for some functions, but still have 588 centralization risk elsewhere. Even when distributed consensus is 589 used exclusively for all functions (which is uncommon, because of the 590 associated costs), some coordination is still necessary -- whether 591 that be through governance of the function itself, creation of shared 592 implementations, or documentation of shared wire protocols. That 593 represents centralization risk, just at a different layer (inherited 594 or platform). 596 These potential shortcomings do not rule out the use of distributed 597 consensus technologies for every use case. They do, however, caution 598 against relying upon these technologies to avoid centralization 599 uncritically. 601 6. What Should Internet Standards Do? 603 Centralization is driven by powerful forces -- both economic and 604 social -- as well as the network effects that come with Internet 605 scale. Because permissionless innovation is a core value for the 606 Internet, and yet much of the centralization seen on the Internet is 607 performed by proprietary platforms that take advantage of this 608 nature, the controls available to standards efforts on their own are 609 very limited. 611 While standards bodies on their own cannot prevent centralization, 612 there are meaningful steps that can be taken to prevent some 613 functions from exhibiting some forms of centralization. There are 614 also valuable contributions that standards efforts can make to other 615 relevant forms of regulation. 617 6.1. Be Realistic 619 Some types of centralization risk are relatively easy to manage in 620 standards efforts. For example, a directly centralized protocol, 621 were it to be proposed, would be rejected out of hand by the IETF. 622 There is a growing body of knowledge and experience with necessary 623 centralization, and a strong inclination to reuse existing 624 infrastructure where possible. As discussed above, encryption is 625 often a way to manage inherited centralization. These responses are 626 appropriate ways for Internet standards to manage centralization 627 risk. 629 However, preventing indirect and platform centralization is much more 630 difficult in standards efforts. Because we have no "protocol 631 police", it's not possible to demand that someone stop building a 632 proprietary service using a purportedly federated protocol. We also 633 cannot stop someone from building centralized services "on top" of 634 standard protocols without abandoning architectural goals like 635 permissionless innovation. 637 Therefore, committing significant resources to scrutinizing protocols 638 for latent centralization risk -- especially for indirect and 639 platform risks -- is unlikely to be effective in preventing Internet 640 centralization. Almost all existing Internet protocols -- including 641 IP, TCP, HTTP, and DNS -- suffer some form of indirect or platform 642 centralization. Refusing to standardize a newer protocol because it 643 faces similar risks would not be equitable, proportionate, or 644 effective. 646 When we find centralization risk, we should consider its relationship 647 with other goals, such as privacy. While there is rarely a pure 648 tradeoff between two abstract goals such as these, when it surfaces 649 attention should be paid to how effective architectural regulation 650 (such as a standards effort) is in achieving each goal. In this 651 example, a technical mechanism might be much more effective at 652 improving privacy, whereas centralization might be better controlled 653 by other regulators -- leading to the conclusion that the standards 654 effort should focus on privacy. 656 6.2. Decentralize Proprietary Functions 658 Standards efforts should particularly focus on creating 659 specifications for functions that are currently only satisfied by 660 proprietary, centralized applications and protocols. For example, if 661 social networking is thought to be a centralized function, this might 662 mean creating specifications that enable decentralized social 663 networking, perhaps using some or all of the techniques described in 664 Section 5. 666 Keen readers will point out that social networking is effectively 667 centralized despite the existence of such standards (see, e.g., 668 [W3C.CR-activitystreams-core-20161215]), because the IETF and W3C 669 create voluntary standards, not mandatory regulations. 671 However, architecture is not the only form of regulation; legal 672 mechanisms combined with changing norms and the resulting market 673 forces have their own regulatory effects [NEW-CHICAGO]. While for 674 much of its lifetime the Internet has only been subject to limited 675 legal regulation, that period appears to be ending. 677 It is far from certain that a legal mandate for interoperability 678 based upon Internet standards will eventuate, but it is increasingly 679 discussed as a remedy for competition issues (see, e.g., [OECD]). It 680 is also uncertain that legally mandated interoperability will fully 681 address centralization risks. However, if such specifications are 682 not available from the Internet community, they may be created 683 elsewhere without reference to the Internet's architectural goals. 685 Even absent a legal mandate, changes in norms and the market -- 686 because of increasing knowledge and distrust of centralized functions 687 -- can create demand for such specifications and the corresponding 688 implementations. 690 6.3. Build Well-Balanced Standards 692 To minimize centralization risk, standards-defined functions should 693 have an explicit goal of broad, diverse implementation and 694 deployment, so that users have as many choices as possible. 696 Section 2.1 of [RFC5218] explores some factors in protocol design 697 that encourage this outcome. 699 This goal can also be furthered by ensuring that the cost of 700 switching to a different implementation or deployment is as low as 701 possible to facilitate subsequent substitution. This implies that 702 the standard is functionally complete and specified precisely enough 703 to result in meaningful interoperability. 705 These goals are sometimes in tension. For example, if a standard is 706 extremely complex, it may discourage implementation diversity because 707 the cost of a complete implementation is too high (consider: Web 708 browsers). On the other hand, if the specification is too simple, it 709 may not offer enough functionality to be complete, and the resulting 710 proprietary extensions may make switching difficult (see 711 Section 6.5). 713 Furthermore, if a new protocol is perceived as completely 714 commoditized (so that no implementation can differentiate itself, and 715 there is no barrier to switching), it may have difficulty achieving 716 broad implementation -- at least by commercial entities. 718 Balancing these factors is difficult, but is often helped by 719 community building and good design -- in particular, appropriate use 720 of layering. 722 6.4. Limit Intermediary Power 724 Some functions might see substantial benefits if intermediation -- 725 i.e., adding a new party to communication to perform a function -- is 726 introduced. When used well, intermediation can help improve: 728 * _Efficiency_: Many functions on the Internet are significantly 729 more efficient when performed at a higher scale. For example, a 730 Content Delivery Network can offer services at a fraction of the 731 financial and environmental cost that would otherwise be paid by 732 someone serving content themselves, because of the scale they 733 operate at. 735 * _Complexity_: Completely disintermediating communication can shift 736 the burden of functions onto endpoints. This can cause increased 737 cognitive load for users; for example, compare commercial social 738 networking platforms with self-hosted efforts. 740 * _Specialization_: Having a function concentrated into relatively 741 few hands can improve outcomes because of the resulting 742 specialization. For example, services overseen by professional 743 administrators are often seen to have a better security posture 744 and improved availability. 746 * _Privacy_: For some functions, user privacy can be improved by 747 concentrating their activity to prevent individual behaviors from 748 being discriminated from each other.[MIX] Intermediation can also 749 enforce functional boundaries -- for example, to reduce the need 750 for users to trust potentially malicious endpoints, as seen in the 751 so-called "oblivious" protocols (e.g., 752 [I-D.pauly-dprive-oblivious-doh]) that allow end users to hide 753 their identity from services, while still accessing them. 755 However, introducing an intermediary role adds indirect and platform 756 centralization risk to Internet protocols, because it brings 757 opportunities for control and observation. While (as discussed 758 above) standards efforts have a very limited capability to prevent or 759 control these types of centralization, constraints on intermediary 760 functions can prevent at least the most egregious outcomes. 762 As a result, intermediaries should only be interposed as a result of 763 the positive action of at least one endpoint, and should have their 764 ability to observe or control communication limited to what is 765 necessary to perform their intended function. 767 For example, early deployments of HTTP allowed intermediaries to be 768 interposed by the network without knowledge of the endpoints, and 769 those intermediaries could see and change the full content of traffic 770 by default -- even when they are only intended to perform basic 771 functions such as caching. Because of the introduction of HTTPS and 772 the CONNECT method (see Section 9.3.6 of [HTTP]), combined with 773 efforts to encourage its adoption, those intermediaries are now 774 required to be explicitly interposed by one endpoint. 776 See [I-D.thomson-tmi] for more guidance on protocol intermediation. 778 The term "intermediary" is also used (often in legal and regulatory 779 contexts) more broadly than it has been in protocol design; for 780 example, an auction Web site intermediates between buyers and sellers 781 is considered an intermediary, even though it is not formally an 782 intermediary in HTTP (see Section 3.7 of [HTTP]). Protocol designers 783 can address the centralization risk associated with this kind of 784 intermediation by standardising the function, rather than restricting 785 the capabilities of the underlying protocols; see Section 6.2. 787 6.5. Avoid Over-Extensibility 789 An important feature of Internet protocols is their ability to 790 evolve, so that they can meet new requirements and adapt to new 791 conditions without requiring a "flag day" to upgrade implementations. 792 Typically, protocols accommodate evolution through extension 793 mechanisms, which allow optional features to be added over time in an 794 interoperable fashion. 796 However, protocol extensions can also increase the risk of platform 797 centralization if a powerful entity can change the target for 798 meaningful interoperability by adding proprietary extensions to a 799 standard protocol. This is especially true when the core standard 800 does not itself provide sufficient utility on its own. 802 For example, the SOAP protocol's [SOAP] extreme flexibility and 803 failure to provide significant standalone value allowed vendors to 804 require use of their preferred extensions, favouring those who had 805 more market power. 807 Therefore, standards efforts should focus on providing concrete 808 utility to the majority of their users as published, rather than 809 being a "framework" where interoperability is not immediately 810 available. Internet protocols should not make every aspect of their 811 operation extensible; extension points should be reasoned, 812 appropriate boundaries for flexibility and control. When a protocol 813 defines extension points, they should not allow an extension to 814 declare itself to be mandatory-to-interoperate, as that pattern 815 invites abuse. 817 7. Security Considerations 819 This document does not have direct security impact on Internet 820 protocols. However, failure to consider centralization risks might 821 cause a myriad of security issues. 823 8. Informative References 825 [ACCESS] Vestager, M., "Defending Competition in a Digitised World, 826 Address at the European Consumer and Competition Day", 827 April 2019, . 832 [BCP95] Alvestrand, H., "A Mission Statement for the IETF", 833 BCP 95, RFC 3935, October 2004. 835 837 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 838 Semantics", Work in Progress, Internet-Draft, draft-ietf- 839 httpbis-semantics-19, 12 September 2021, 840 . 843 [I-D.pauly-dprive-oblivious-doh] 844 Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 845 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 846 Internet-Draft, draft-pauly-dprive-oblivious-doh-10, 31 847 January 2022, . 850 [I-D.thomson-tmi] 851 Thomson, M., "Principles for the Involvement of 852 Intermediaries in Internet Protocols", Work in Progress, 853 Internet-Draft, draft-thomson-tmi-02, 6 July 2021, 854 . 857 [INTERMEDIARY-INFLUENCE] 858 Judge, K., "Intermediary Influence", 2014, 859 . 862 [LEGITIMACY-MULTI] 863 Palladino, N. and N. Santaniello, "Legitimacy, Power, and 864 Inequalities in the Multistakeholder Internet Governance", 865 2020. 867 [MIX] Chaum, D.L., "Untraceable Electronic Mail, Return 868 Addresses, and Digital Pseudonyms", February 1981, 869 . 871 [MOXIE] Marlinspike, M., "Reflections: The ecosystem is moving", 872 May 2016, 873 . 875 [NEW-CHICAGO] 876 Lessig, L., "The New Chicago School", June 1998. 878 [OECD] OECD, "Data portability, interoperability and digital 879 platform competition", June 2021, 880 . 884 [PIR] Olumofin, F. and I. Goldberg, "Revisiting the 885 Computational Practicality of Private Information 886 Retrieval", 2010. 888 [POLYCENTRIC] 889 Aligia, P.D. and V. Tarko, "Polycentricity: From Polanyi 890 to Ostrom, and Beyond", April 2012. 892 [RAND] Baran, P., "On Distributed Communications: Introduction to 893 Distributed Communications Networks", 1964, 894 . 897 [RFC1035] Mockapetris, P., "Domain names - implementation and 898 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 899 November 1987, . 901 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 902 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 903 DOI 10.17487/RFC4271, January 2006, 904 . 906 [RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful 907 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 908 . 910 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 911 DOI 10.17487/RFC5321, October 2008, 912 . 914 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 915 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 916 March 2011, . 918 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 919 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 920 2014, . 922 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 923 DOI 10.17487/RFC0791, September 1981, 924 . 926 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 927 RFC 793, DOI 10.17487/RFC0793, September 1981, 928 . 930 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, 931 DOI 10.17487/RFC8890, August 2020, 932 . 934 [SCALE-FREE] 935 Albert, R., "Emergence of Scaling in Random Networks", 936 October 1999, . 938 [SOAP] Mitra, N. and Y. Lafon, "SOAP Version 1.2 Part 0: Primer 939 (Second Edition)", World Wide Web Consortium 940 Recommendation REC-soap12-part0-20070427, 27 April 2007, 941 . 943 [TECH-SUCCESS-FACTORS] 944 Kende, M., Kvalbein, A., Allford, J., and D. Abecassis, 945 "Study on the Internet's Technical Success Factors", 946 December 2021, . 950 [W3C.CR-activitystreams-core-20161215] 951 Snell, J. and E. Prodromou, "Activity Streams 2.0", World 952 Wide Web Consortium CR CR-activitystreams-core-20161215, 953 15 December 2016, . 956 [WEAPONIZED-INTERDEPENDENCE] 957 Farrell, H. and A.L. Newman, "Weaponized Interdependence: 958 How Global Economic Networks Shape State Coercion", 2019, 959 . 961 Appendix A. Acknowledgements 963 This document benefits from discussions with Brian Trammell during 964 our shared time on the Internet Architecture Board. 966 Author's Address 968 Mark Nottingham 969 Prahran 970 Australia 972 Email: mnot@mnot.net 973 URI: https://www.mnot.net/