idnits 2.17.00 (12 Aug 2021) /tmp/idnits55649/draft-nottingham-avoiding-internet-centralization-01.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.) ** 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 722: '... potential SHOULD be as minimal as p...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (9 January 2022) is 131 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RAND' is defined on line 838, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-09 == Outdated reference: A later version (-03) exists of draft-thomson-tmi-02 Summary: 2 errors (**), 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 January 2022 4 Intended status: Informational 5 Expires: 13 July 2022 7 Centralization and Internet Standards 8 draft-nottingham-avoiding-internet-centralization-01 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 July 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 . . . . . . . . . . . . . . . . . . 4 68 4. Kinds of Centralization . . . . . . . . . . . . . . . . . . . 6 69 4.1. Direct Centralization . . . . . . . . . . . . . . . . . . 6 70 4.2. Necessary Centralization . . . . . . . . . . . . . . . . 6 71 4.3. Indirect Centralization . . . . . . . . . . . . . . . . . 7 72 4.4. Inherited Centralization . . . . . . . . . . . . . . . . 8 73 4.5. Platform Centralization . . . . . . . . . . . . . . . . . 9 74 5. The Limits of Decentralization . . . . . . . . . . . . . . . 9 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? . . . . . . . . . . . . . 13 79 6.1. Manage Centralization Risk Where Effective . . . . . . . 14 80 6.2. Create Standards to Decentralize Proprietary Functions . 15 81 6.3. Limit Intermediary Power . . . . . . . . . . . . . . . . 15 82 6.4. Avoid Over-Extensibility . . . . . . . . . . . . . . . . 16 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 84 8. Informative References . . . . . . . . . . . . . . . . . . . 17 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 20 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 88 1. Introduction 90 The Internet has succeeded in no small part because of its purposeful 91 avoidance of any single controlling entity. While this approach may 92 reflect a desire to prevent a single technical failure from having 93 wide impact,[RAND] it has also enabled the Internet's rapid adoption 94 and broad spread, because internetworking did not require obtaining 95 permission from or ceding control to another entity -- thereby 96 accommodating a spectrum of requirements and positioning the Internet 97 as a public good. 99 While avoiding centralization is a widely shared goal for the 100 Internet, meeting that goal has proven difficult. Many successful 101 protocols and applications on the Internet today are designed or 102 operated in a centralized fashion -- to the point where some 103 proprietary, centralized services have become so well-known that they 104 are commonly mistaken for the Internet itself. Even when protocols 105 incorporate techniques intended to prevent centralization, economic 106 and social factors can drive users to prefer centralized solutions 107 built with or on top of supposedly decentralized technology. 109 These difficulties call into question what role architectural 110 regulation -- in particular, open standards bodies such as at the 111 IETF -- should be play in preventing, mitigating, and controlling 112 centralization of the Internet. 114 This document discusses aspects of centralization that relate to 115 Internet standards efforts. Section 2 provides a definition of 116 centralization. Section 3 explains why centralization of Internet's 117 functions is undesirable. Section 4 surveys the different kinds of 118 centralization that might surface on the Internet. Section 5 then 119 catalogues high-level approaches to mitigating centralization and 120 discusses their limitations. Finally, Section 6 considers the role 121 that Internet standards play in avoiding centralization and 122 mitigating its effects. 124 Engineers who design and standardize Internet protocols are the 125 primary audience for this document. However, designers of 126 proprietary protocols can benefit from considering aspects of 127 centralization, especially if they intend their protocol to be 128 considered for eventual standardisation. Likewise, policymakers can 129 use this document to help identify and remedy inappropriately 130 centralized protocols and applications. 132 2. What is Centralization 134 This document defines "centralization" as the ability of a single 135 entity (e.g., a person, company, or government) -- or a small group 136 of them -- to observe, control, or extract rent from the operation or 137 use of a given function on the Internet. 139 Here, "function" is defined broadly. It might be an enabling 140 protocol already defined by standards, such as IP [RFC791], BGP 141 [RFC4271], TCP [RFC793], or HTTP [HTTP]. It might also be a proposal 142 for a new enabling protocol, or an extension to an existing one. 144 However, centralization is not limited to standards-defined 145 protocols. User-visible applications built on top of the functions 146 provided by standards are also vulnerable to centralization -- for 147 example, social networking, file sharing, financial services, and 148 news dissemination. Likewise, the supply of hardware, operating 149 systems, and software can exhibit centralization. 151 Centralization risk is strongest when it necessarily affects the 152 entire Internet. However, it can also be present when a substantial 153 portion of the Internet's users lack options for a given function. 154 For example, if there is only one provider a function in a given 155 region or legal jurisdiction, that function is effectively 156 centralized for those users. 158 "Decentralization" is the process of identifying centralization risk 159 in the functions of a protocol or application, followed by 160 application of appropriate techniques to prevent or mitigate 161 centralization. 163 Decentralization does not require that a given function need be so 164 widely distributed that other important factors, such as efficiency, 165 resiliency, latency, or availability are sacrificed. In some cases, 166 a function that is only available through a relatively small number 167 of providers can be effectively decentralized, given the appropriate 168 circumstances (see, for example, the DNS). 170 Therefore, discussions of centralization and architectural efforts at 171 decentralization need to be made on a case-by-base basis, depending 172 on the function in question, surrounding circumstances, and other 173 regulatory mechanisms. 175 Note that it is important to distinguish centralization from anti- 176 competitive concerns (also known as "anti-trust"). While there are 177 many interactions between them and making the Internet more 178 competitive may be a motivation for avoiding centralization, only 179 courts are authoritative in determining what is and is not anti- 180 competitive in a given market, not standards bodies and other 181 technical fora. 183 3. Why Avoid Centralization 185 Centralization is undesirable because it is counter to the nature of 186 the Internet, because it violates the end users' expectations, and 187 because of the many negative effects it can have on the networks 188 operation and evolution. 190 Firstly, the Internet's very nature is incompatible with 191 centralization of its functions. As a 'large, heterogeneous 192 collection of interconnected systems' [BCP95] the Internet is often 193 characterised as a 'network of networks'. As such, these networks 194 relate as peers who agree to facilitate communication, rather than 195 having a relationship of subservience to others' requirements or 196 coercion by them. 198 Secondly, as the Internet's first duty is to the end user [RFC8890], 199 allowing such power to be concentrated into few hands is counter to 200 the IETF's mission of creating an Internet that 'will help us to 201 build a better human society.' [BCP95] When a third party has 202 unavoidable access to communications, the 'informational and 203 positional advantages' [INTERMEDIARY-INFLUENCE] gained can be used to 204 observe behavior (the 'panopticon effect') and shape or even deny 205 behaviour (the 'chokepoint effect') -- which can be used by those 206 parties (or the states that have authority over them) for coercive 207 ends. [WEAPONIZED-INTERDEPENDENCE] 209 Finally, concentration of power has deleterious effects on the 210 Internet itself, including: 212 * _Limiting Innovation_: Centralization can preclude the possibility 213 of 'permissionless innovation' -- the ability to deploy new, 214 unforeseen applications without requiring coordination with 215 parties other than those you are communicating with. 217 * _Constraining Competition_: The Internet and its users benefit 218 from robust competition when applications and services are 219 available from many different providers -- especially when those 220 users can build their own applications and services based upon 221 interoperable standards. When dependencies are formed on a 222 centralized service or platform, it effectively becomes an 223 essential facility, which encourages abuse of power. 225 * _Reducing Availability_: The Internet's availability (as well as 226 applications and services built upon it) improves when there are 227 many ways to obtain access to it. While centralized services 228 typically benefit from the focused attention that their elevated 229 role requires, when they do fail the resulting loss of 230 availability can have disproportionate impact. 232 * _Creating Monoculture_: At the scale available to a centralized 233 service or application, minor flaws in features such as 234 recommendation algorithms can be magnified to a degree that can 235 have broad (even societal) consequences. Diversity in the 236 implementation of these functions is significantly more robust, 237 when viewed systemically. [POLYCENTRIC] 239 * _Self-Reinforcement_: As widely noted (see, eg., [ACCESS]), a 240 centralized service benefits from access to data which can be used 241 to further improve its offerings, while denying such access to 242 others. 244 See also [TECH-SUCCESS-FACTORS]. 246 To summarize, centralization would allow the Internet (or some part 247 of it) to be captured, effectively turning it into a 'walled garden' 248 that fails to meet both architectural design goals and users' 249 expectations, and endangering its ongoing viability at the same time. 251 4. Kinds of Centralization 253 Centralization of the Internet is not uniform; it presents in a 254 variety of ways, depending on its relationship to the function in 255 question and underlying causes. The subsections below offer the 256 start of a classification system for Internet centralization. 258 4.1. Direct Centralization 260 The most straightforward kind of centralization creates a fixed role 261 for a specific party. For example, most proprietary messaging, 262 videoconferencing, chat, and similar protocols operate in this 263 fashion. 265 While it has been argued that such protocols are simpler to design, 266 more amenable to evolution, and more likely to meet user needs 267 [MOXIE], this approach most often reflects commercial goals -- in 268 particular, a strong desire to capture the financial benefits of the 269 protocol by 'locking in' users to a proprietary service. 271 Directly centralised protocols and applications are not considered to 272 be part of the Internet per se; instead, they are more properly 273 characterized as proprietary protocols that are built on top of the 274 Internet. As such, they are not regulated by the Internet 275 architecture or standards, beyond the constraints that the underlying 276 protocols (e.g., TCP, IP, HTTP) impose. 278 4.2. Necessary Centralization 280 Some protocols require the introduction of centralization risk that 281 is unavoidable by nature. 283 For example, when there is a need a single, globally coordinated 284 'source of truth', that function is by nature centralized. The most 285 obvious instance is seen in the Domain Name System (DNS), which 286 allows human-friendly naming to be converted into network addresses 287 in a globally consistent fashion. 289 Allocation of IP addresses is another example of a necessary function 290 being a centralization risk. Internet routing requires addresses to 291 be allocated uniquely, but if the addressing function were captured 292 by a single government or company, the entire Internet would be at 293 risk of abuse by that entity. 295 Similarly, the need for coordination in the Web's trust model brings 296 centralization risk, because a Certificate Authority (CA) can control 297 communication between the Web sites that they sign certificates for 298 and users whose browsers trust the CA's root certificates. 300 Protocols that need to solve the "rendezvous problem" to coordinate 301 communication between two parties that are not in direct contact also 302 suffer from this kind of centralization risk. For example, chat 303 protocols need a way to coordinate communication between two parties 304 that wish to talk; while the actual communication can be direct 305 between them (so long as the protocol facilitates that), the 306 endpoints' mutual discovery typically requires a third party. 308 Internet protocols often attempt to mitigate necessary centralization 309 risk using measures such as mandated federation Section 5.1 and 310 multi-stakeholder administration Section 5.2. 312 Because of the inherent risks and costs of these approaches, 313 functions that successfully use these techniques are often reused by 314 others with similar requirements. For example, if a protocol 315 requires a coordinated, global naming function, reusing the Domain 316 Name System is usually preferable to establishing a new system, 317 because its centralization risk is known and understood, and the 318 risks inherent in establishing new mitigations are avoided. 320 4.3. Indirect Centralization 322 Even when a protocol avoids direct centralization and does not 323 exhibit any necessary centralization, it might become centralized in 324 practice when external factors influence its deployment. Indirect 325 centralization can be caused by factors that encourage use of a 326 central function despite the absence of such a requirement in the 327 protocol itself. Such factors might be economic, social, or legal. 329 Often, the factors driving indirect centralization are related to the 330 network effects that are so often seen on the Internet. While in 331 theory every node on the Internet is equal, in practice some nodes 332 are much more connected than others: for example, just a few sites 333 drive much of the traffic on the Web. While expected and observed in 334 many kinds of networks [SCALE-FREE], network effects award asymmetric 335 power to nodes that act as intermediaries to communication. 337 Left unchecked, these factors can cause a potentially decentralized 338 application to become directly centralised, because the central 339 function has leverage to "lock in" users. For example, social 340 networking is an application that is currently supplied by a small 341 number of directly centralized, proprietary platforms despite 342 standardization efforts (see, e.g., 343 [W3C.CR-activitystreams-core-20161215]), due to the powerful network 344 effects associated. 346 By its nature, indirect centralization is difficult to avoid in 347 protocol design, and federated protocols are particularly vulnerable 348 to it (see Section 5.1). 350 4.4. Inherited Centralization 352 Most Internet protocols depend on other, "lower-layer" protocols. 353 The features, deployment, and operation of these dependencies can 354 surface centralization risk into functions and applications build "on 355 top" of them. 357 For example, the network between endpoints can introduce 358 centralization risk to application-layer protocols, because it is 359 necessary for communication and therefore has power over it. A given 360 network might block access to, slow down, or modify the content of 361 various application protocols or specific services for financial, 362 political, operational, or criminal reasons, thereby creating 363 pressure to use other services, which can in turn result in 364 centralization of them. 366 Inherited centralization risk is only present when users cannot use 367 an alternative means of accessing the desired service. For example, 368 users often have flexibility in choice of Internet access, so they 369 could just "route around" a network that impacts their chosen 370 service. However, such choices are often not available in the 371 moment, and the Internet's topology means that a choke point upstream 372 could still affect their Internet access. 374 When deployed at scale, encryption can be an effective technique to 375 control many inherited centralization risks. By reducing the number 376 of parties who have access to content of communication, the ability 377 of lower-layer protocols and intermediaries at those layers to 378 interfere with or observe is precluded. Even when they can still 379 prevent communication, the use of encryption makes it more difficult 380 to discriminate the target from other traffic. 382 Note that the prohibitive effect on inherited centralization is most 383 pronounced when most (if not all) traffic is encrypted -- providing 384 yet more motivation for that goal (see also [RFC7258]). 386 4.5. Platform Centralization 388 The complement to inherited centralization is platform centralization 389 -- where a function does not directly define a central role, but 390 could facilitate centralization in the applications it supports. 392 For example, HTTP [HTTP] in itself is not considered a centralized 393 protocol; interoperable servers are relatively easy to instantiate, 394 and multiple clients are available. It can be used without central 395 coordination beyond that provided by DNS, as discussed above. 397 However, applications built on top of HTTP (as well as the rest of 398 the 'Web Platform') often exhibit centralization. As such, HTTP is 399 an example of a platform for centralization -- while the protocol 400 itself is not centralized, it does facilitate the creation of 401 centralized services and applications. 403 Like indirect centralization, platform centralization is difficult to 404 completely avoid in protocol design. Because of the layered nature 405 of the Internet, most protocols are designed to allow considerable 406 flexibility in how they are used, often in a way that it becomes 407 attractive to form a dependency on one party's operation. Notably, 408 this can happen even if the protocol does not accommodate 409 intermediation explicitly. 411 5. The Limits of Decentralization 413 Over time, various techniques have been developed to decentralize 414 protocols and applications. While these approaches can be used to 415 create a function which is less centralized or less amenable to some 416 kinds of centralization, they are not adequate to completely avoid 417 centralization on their own. As such, while the use of these 418 techniques is often appropriate and sometimes effective, they are not 419 indicators of whether a protocol is centralized without further 420 analysis. 422 5.1. Federation isn't Enough 424 A widely known technique for managing centralization in Internet 425 protocols is federation -- that is, designing them in such a way that 426 new instances of any intermediary or otherwise centralized function 427 are relatively easy to create, and they are able to maintain 428 interoperability and connectivity with other instances. 430 For example, SMTP [RFC5321] is the basis of the e-mail suite of 431 protocols, which has two functions that are necessarily centralized: 433 1. Giving each user a globally unique address, and 435 2. Routing messages to the user, even when they change network 436 locations or are disconnected for long periods of time. 438 E-mail reuses DNS to help mitigate the first risk. To mitigate the 439 second, it defines an intermediary role for routing users' messages, 440 the Message Transfer Agent (MTA). By allowing anyone to deploy a MTA 441 and defining rules for interconnecting them, the protocol's users 442 avoid a requirement for a single, central router. 444 Users can (and often do) choose to delegate that role to someone 445 else, or run their own MTA. However, running your own mail server 446 has become difficult, due to the likelihood of a small MTA being 447 classified as a spam source. Because large MTA operaters are widely 448 known and have greater impact if their operation is affected, they 449 are less likely to be classified as such, thereby indirectly 450 centralizing the protocol's operation (see Section 4.3). 452 Another example of a federated Internet protocol is XMPP [RFC6120], 453 supporting "instant messaging" and similar functionality. Like 454 e-mail, it reuses DNS for naming and requires federation to 455 facilitate rendezvous of users from different systems. 457 While some deployments of XMPP do support truly federated messaging 458 (i.e., a person using service A can interoperably chat with someone 459 using service B), many of the largest do not. Because federation is 460 voluntary, some operators made a decision to capture their users into 461 a single service, rather than provide the benefits of global 462 interoperability. 464 The examples above illustrate that federation can be a useful 465 technique to avoid direct centralization and manage necessary 466 centralization, but on its own is not sufficient to avoid indirect 467 and platform centralization. If the value provided by a protocol can 468 be captured by a single entity, they may use the protocol as a 469 platform to obtain a 'winner take all' outcome -- a significant risk 470 with many Internet protocols, since network effects often promote 471 such outcomes. Likewise, external factors (such as spam control) 472 might naturally 'tilt the table' towards a few operators of these 473 protocols. 475 5.2. Multi-Stakeholder Administration is Hard 477 Delegating the administration of a necessarily centralized function 478 (see Section 4.2) to a multi-stakeholder body is occasionally used to 479 mitigate its effects. 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 Domain Name System [RFC1035], which as a "single source of truth" 488 exhibits necessary centralization of the naming function, as well as 489 the operation of the system. To mitigate operational centralization, 490 this task is carried out by multiple root servers that are 491 administered by separate operators -- themselves diverse in geography 492 and a selection of corporate entities, non-profits and government 493 bodies from many jurisdictions and affiliations. Furthermore, the 494 name space itself is regulated by 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 the behavior of implementations that are conformant with it, 502 the standardization process can be seen as a single point of control. 503 As a result, Internet standards bodies like the IETF allow open 504 participation and contribution, make decisions in an open and 505 accountable way, have a well-defined process for making (and when 506 necessary, appealing) decisions, taking into account the views of 507 different stakeholder groups [RFC8890]. 509 Yet another example is the administration of the Web's trust model, 510 implemented by Web browsers as relying parties and Certificate 511 Authorities as trust anchors. To assure that all parties meet the 512 operational and security requirements necessary to provide the 513 desired properties, the CA/Browser Forum (https://cabforum.org) was 514 established as an oversight body that involves both of those parties 515 as stakeholders. 517 In each of these examples, setup and ongoing operation of a multi- 518 stakeholder organization is not trivial. This is a major downside of 519 this approach. Additionally, the legitimacy of such an organization 520 cannot be assumed, and may be difficult to establish and maintain 521 (see, eg, [LEGITIMACY-MULTI]). This concern is especially relevant 522 if the function being coordinated is broad, complex, and/or 523 contentious. 525 5.3. Blockchains Are Not Magical 527 Increasingly, distributed consensus technologies such as the 528 blockchain are touted as a solution to centralization issues. A 529 complete survey of this rapidly-changing area is beyond the scope of 530 this document, but at a high level, we can generalise about their 531 properties. 533 These techniques attempt to avoid centralization risk by distributing 534 intermediary or otherwise potentially centralized functions to 535 members of a large pool of protocol participants. Verification of 536 proper performance of a function is typically guaranteed using 537 cryptographic techniques (often, an append-only transaction ledger). 538 The assignment of a particular task to a node for handling usually 539 cannot be predicted or controlled. 541 Sybil attacks (where enough participants coordinate their activity to 542 affect the protocol's operation) are a major concern for these 543 protocols. Diversity in the pool of participants is encouraged using 544 indirect techniques such as proof-of-work (where each participant has 545 to demonstrate significant consumption of resources) or proof-of- 546 stake (where each participant has some other incentive to execute 547 correctly). 549 Appropriate use of these techniques can create barriers to direct and 550 inherited centralization. However, depending upon the application in 551 question, indirect and platform centralization can still be possible. 553 Furthermore, distributed consensus technologies have several 554 potential shortcomings that may make them inappropriate -- or at 555 least difficult to use -- for many Internet applications, because 556 their use conflicts with other important goals: 558 1. Distributed consensus protocols can have significant implications 559 for privacy. Because activity (such as queries or transactions) 560 are shared with many unknown parties, they have very different 561 privacy properties than traditional client/server protocols. 562 Mitigations (e.g., Private Information Retrieval; see, eg, [PIR]) 563 are still not suitable for broad deployment. 565 2. Their complexity and "chattiness" typically result in 566 significantly less efficient use of the network (often, to 567 several orders of magnitude). When distributed consensus 568 protocols use proof-of-work, energy consumption can become 569 significant (to the point where some jurisdictions have banned 570 its use). 572 3. Distributed consensus protocols are still not proven to scale to 573 the degree expected of successful Internet protocols. In 574 particular, relying on unknown third parties to deliver 575 functionality can introduce variability in latency, availability, 576 and throughput. This is a marked change for applications with 577 high expectations for these properties (e.g., commercial Web 578 services). 580 4. By design, distributed consensus protocols diffuse responsibility 581 for a function among several, difficult-to-identify parties. 582 While this may be an effective way to prevent some kinds of 583 centralization, it also means that making someone accountable for 584 how the function is performed is impossible, beyond the bounds of 585 the protocol's design. 587 It is also important to recognise that a protocol or an application 588 can use distributed consensus for some functions, but still have 589 centralization risk elsewhere. Even when distributed consensus is 590 used exclusively (which is uncommon, due to the associated costs), 591 some degree of coordination is still necessary -- whether that be 592 through governance of the function itself, creation of shared 593 implementations, or documentation of shared wire protocols. That 594 represents centralization risk, just at a different layer (inherited 595 or platform, depending on the circumstances). 597 These potential shortcomings do not rule out the use of distributed 598 consensus technologies for every use case. They do, however, caution 599 against relying upon these technologies to avoid centralization 600 uncritically. 602 6. What Should Internet Standards Do? 604 Centralization is driven by powerful forces -- both economic and 605 social -- as well as the network effects that come with Internet 606 scale. Moreover, because permissionless innovation is a core value 607 for the Internet, and yet much of the centralization seen on the 608 Internet is performed by proprietary platforms that take advantage of 609 this nature, the controls available to standards efforts on their own 610 are very limited. 612 Nevertheless, while standards bodies on their own cannot prevent 613 centralization, there are meaningful steps that can be taken to 614 prevent some functions from exhibiting some forms of centralization. 615 There are also valuable contributions that standards efforts can make 616 to other relevant forms of regulation. 618 6.1. Manage Centralization Risk Where Effective 620 Some types of centralization risk are relatively easy to manage in 621 standards efforts. A directly centralized protocol, were it to be 622 proposed, would be rejected out of hand by the IETF. There is a 623 growning body of knowledge and experience with necessary 624 centralization, and a strong inclination to reuse existing 625 infrastructure where possible. As discussed above, encryption is 626 often a way to manage inherited centralization. All of these 627 responses are appropriate ways for Internet standards to manage 628 centralization risk. 630 However, precluding indirect and platform centralization are much 631 more difficult in standards efforts. Because we have no "protocol 632 police", it's not possible to demand that someone stop building a 633 proprietary service using a purportedly federated protocol. We also 634 cannot stop someone from building centralized services "on top" of 635 standard protocols without violating architectural goals like 636 permissionless innovation. 638 Therefore, committing significant resources to scrutinizing protocols 639 for hidden or latent centralization risk -- especially for indirect 640 and platform risks -- is unlikely to actually prevent Internet 641 centralization. Almost all existing Internet protocols -- including 642 IP, TCP, HTTP, and DNS -- suffer some form of indirect or platform 643 centralization. Refusing to standardize a newer protocol because it 644 faces similar risks would not be equitable, proportionate, or 645 effective. 647 Centralization risk is sometimes perceived to be in tension with 648 other goals, such as privacy. While there is rarely a pure tradeoff 649 between two abstract goals such as these, when it does occur 650 attention should be paid to how effective architectural regulation 651 (such as a standards effort) is in achieving each goal. In this 652 example, a technical mechanism might be much more effective at 653 improving privacy, whereas centralization might be better controlled 654 by other regulators -- leading to the conclusion that the standards 655 effort should focus on privacy. 657 6.2. Create Standards to Decentralize Proprietary Functions 659 Standards efforts should focus on creating new specifications for 660 functions that are currently only satisfied by proprietary, 661 centralized protocols. For example, if social networking is thought 662 to be a centralized function, this might mean creating specifications 663 that enable decentralized social networking, perhaps using some or 664 all of the techniques described in 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 not certain that legally-mandated standards 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 -- due 686 to increasing knowledge and distrust of centralized functions -- can 687 create demand for such specifications and the corresponding 688 implementations. 690 6.3. Limit Intermediary Power 692 The introduction of an intermediary role -- i.e., one that performs a 693 function but is not a first party to communication -- adds indirect 694 and platform centralization risk to Internet protocols, because it 695 brings opportunities for control and observation. At the same time, 696 intermediation often adds significant value to a protocol, or enables 697 what is considered a necessary function. 699 While (as discussed above) standards efforts have a very limited 700 capability to prevent or control indirect and platform 701 centralization, constraints on intermediary functions -- when 702 designed explicitly into a protocol -- and prevent at least the most 703 egregious outcomes. In general, this can be achieved by limiting the 704 nature of the intermediary role to the most minimal function 705 possible. 707 For example, HTTP allows intermediaries to see the full content of 708 traffic by default, even when they are only performing basic 709 functions such as routing. However, with the introduction of HTTPS 710 and the CONNECT method (see Section 9.3.6 of [HTTP]), combined with 711 market forces to adopt HTTPS, those intermediaries now only have 712 access to the appropriate routing information. 714 When carefully considered, intermediation can be a powerful way to 715 enforce functional boundaries -- for example, to reduce the need for 716 users to trust potentially malicious endpoints, as seen in the so- 717 called 'oblivious' protocols currently in development (e.g., 718 [I-D.pauly-dprive-oblivious-doh]) that allow end users to hide their 719 identity from services, while still accessing them. 721 The same advice applies in these cases; the observation and control 722 potential SHOULD be as minimal as possible, while still meeting the 723 design goals of the protocol. 725 See [I-D.thomson-tmi] for more guidance. 727 Another kind of intermediation is created when a new feature or 728 service is built using a standard as a substrate. For example, many 729 Web sites offer new functions like social networking and aggregated 730 news updates that can be viewed as a proprietary intermediary 731 function on the Internet. These intermediaries may not be a format 732 part of the underlying protocol (in the case of Web sites, HTTP), but 733 they can still interpose a third party into communication. This kind 734 of intermediation is more effectively dealt with by standardising the 735 function, rather than restricting the capability of the protocol; see 736 Section 6.2. 738 6.4. Avoid Over-Extensibility 740 An important feature of Internet protocols is their ability to evolve 741 over time, so that they can meet new requirements and adapt to new 742 conditions without requiring a "flag day" to upgrade implementations. 743 Typically, protocol evolution is accommodated through extension 744 mechanisms, where optional features can be added over time in an 745 interoperable fashion. 747 However, protocol extensions can also increase the risk of platform 748 centralization if a powerful entity can change the target for 749 meaningful interoperability by adding proprietary extensions to a 750 standard protocol. This is especially true when the core standard 751 does not itself provide sufficient utility on its own. 753 For example, the SOAP protocol [SOAP] was an extremely flexible 754 framework, allowing vendors to attempt to capture the market by 755 requiring use of their preferred extensions to interoperate. 757 Therefore, standards efforts should be focused on providing concrete 758 utility to the majority of their users as published, rather than 759 being a "framework" where interoperability is not immediately 760 available. Furthermore, Internet protocols should not make every 761 aspect of their operation extensible; extension points should be 762 reasoned, appropriate boundaries for flexibility and control. When 763 extension points are defined, they should not allow an extension to 764 declare itself to be mandatory-to-interoperate, as that pattern 765 invites abuse. 767 7. Security Considerations 769 This document does not have direct security impact on Internet 770 protocols. However, failure to consider centralization risks might 771 result in a myriad of security issues. 773 8. Informative References 775 [ACCESS] Vestager, M., "Defending Competition in a Digitised World, 776 Address at the European Consumer and Competition Day", 777 April 2019, . 782 [BCP95] Alvestrand, H., "A Mission Statement for the IETF", 783 BCP 95, RFC 3935, October 2004. 785 787 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 788 Semantics", Work in Progress, Internet-Draft, draft-ietf- 789 httpbis-semantics-19, 12 September 2021, 790 . 793 [I-D.pauly-dprive-oblivious-doh] 794 Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 795 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 796 Internet-Draft, draft-pauly-dprive-oblivious-doh-09, 5 797 January 2022, . 800 [I-D.thomson-tmi] 801 Thomson, M., "Principles for the Involvement of 802 Intermediaries in Internet Protocols", Work in Progress, 803 Internet-Draft, draft-thomson-tmi-02, 6 July 2021, 804 . 807 [INTERMEDIARY-INFLUENCE] 808 Judge, K., "Intermediary Influence", 2014, 809 . 812 [LEGITIMACY-MULTI] 813 Palladino, N. and N. Santaniello, "Legitimacy, Power, and 814 Inequalities in the Multistakeholder Internet Governance", 815 2020. 817 [MOXIE] Marlinspike, M., "Reflections: The ecosystem is moving", 818 May 2016, 819 . 821 [NEW-CHICAGO] 822 Lessig, L., "The New Chicago School", June 1998. 824 [OECD] OECD, "Data portability, interoperability and digital 825 platform competition", June 2021, 826 . 830 [PIR] Olumofin, F. and I. Goldberg, "Revisiting the 831 Computational Practicality of Private Information 832 Retrieval", 2010. 834 [POLYCENTRIC] 835 Aligia, P.D. and V. Tarko, "Polycentricity: From Polanyi 836 to Ostrom, and Beyond", April 2012. 838 [RAND] Baran, P., "On Distributed Communications: Introduction to 839 Distributed Communications Networks", 1964, 840 . 843 [RFC1035] Mockapetris, P., "Domain names - implementation and 844 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 845 November 1987, . 847 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 848 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 849 DOI 10.17487/RFC4271, January 2006, 850 . 852 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 853 DOI 10.17487/RFC5321, October 2008, 854 . 856 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 857 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 858 March 2011, . 860 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 861 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 862 2014, . 864 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 865 DOI 10.17487/RFC0791, September 1981, 866 . 868 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 869 RFC 793, DOI 10.17487/RFC0793, September 1981, 870 . 872 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, 873 DOI 10.17487/RFC8890, August 2020, 874 . 876 [SCALE-FREE] 877 Albert, R., "Emergence of Scaling in Random Networks", 878 October 1999, . 880 [SOAP] Mitra, N. and Y. Lafon, "SOAP Version 1.2 Part 0: Primer 881 (Second Edition)", World Wide Web Consortium 882 Recommendation REC-soap12-part0-20070427, 27 April 2007, 883 . 885 [TECH-SUCCESS-FACTORS] 886 Kende, M., Kvalbein, A., Allford, J., and D. Abecassis, 887 "Study on the Internet's Technical Success Factors", 888 December 2021, . 892 [W3C.CR-activitystreams-core-20161215] 893 Snell, J. and E. Prodromou, "Activity Streams 2.0", World 894 Wide Web Consortium CR CR-activitystreams-core-20161215, 895 15 December 2016, . 898 [WEAPONIZED-INTERDEPENDENCE] 899 Farrell, H. and A.L. Newman, "Weaponized Interdependence: 900 How Global Economic Networks Shape State Coercion", 2019, 901 . 903 Appendix A. Acknowledgements 905 This document benefits from discussions with Brian Trammell during 906 our shared time on the Internet Architecture Board. 908 Author's Address 910 Mark Nottingham 911 Prahran 912 Australia 914 Email: mnot@mnot.net 915 URI: https://www.mnot.net/