idnits 2.17.00 (12 Aug 2021) /tmp/idnits55169/draft-nottingham-avoiding-internet-centralization-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (8 December 2021) is 163 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MOXIE' is defined on line 773, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-pauly-dprive-oblivious-doh-08 == Outdated reference: A later version (-03) exists of draft-thomson-tmi-02 Summary: 1 error (**), 0 flaws (~~), 4 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 8 December 2021 4 Intended status: Informational 5 Expires: 11 June 2022 7 Avoiding Internet Centralization 8 draft-nottingham-avoiding-internet-centralization-00 10 Abstract 12 Avoiding centralization is an important goal for Internet protocols. 13 This document offers a definition of centralization, discusses why it 14 is necessary for Internet protocol designers to consider its risks, 15 identifies different kinds of centralization, catalogues some 16 limitations of current approaches to controlling it, and recommends 17 best practices for protocol designers. 19 About This Document 21 This note is to be removed before publishing as an RFC. 23 Status information for this document may be found at 24 https://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet- 25 centralization/. 27 Source for this draft and an issue tracker can be found at 28 https://github.com/mnot/avoiding-internet-centralization. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 11 June 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 65 2. Why Avoid Centralization . . . . . . . . . . . . . . . . . . 4 66 3. Kinds of Centralization . . . . . . . . . . . . . . . . . . . 6 67 3.1. Direct Centralization . . . . . . . . . . . . . . . . . . 6 68 3.2. Necessary Centralization . . . . . . . . . . . . . . . . 6 69 3.3. Indirect Centralization . . . . . . . . . . . . . . . . . 7 70 3.4. Inherited Centralization . . . . . . . . . . . . . . . . 8 71 3.5. Platform Centralization . . . . . . . . . . . . . . . . . 8 72 4. The Limits of Decentralization . . . . . . . . . . . . . . . 9 73 4.1. Federation isn't Enough . . . . . . . . . . . . . . . . . 9 74 4.2. Multi-Stakeholder Administration is Hard . . . . . . . . 10 75 4.3. Blockchains Are Not Magical . . . . . . . . . . . . . . . 11 76 5. Guidelines for Protocol Designers . . . . . . . . . . . . . . 13 77 5.1. Allow Intermediation Sparingly . . . . . . . . . . . . . 13 78 5.2. Encrypt, Always . . . . . . . . . . . . . . . . . . . . . 14 79 5.3. Reuse Existing Tools . . . . . . . . . . . . . . . . . . 14 80 5.4. Accomodate Limited Domains Warily . . . . . . . . . . . . 15 81 5.5. Target Extensibility . . . . . . . . . . . . . . . . . . 15 82 5.6. Acknowledge the Limits of Protocol Design . . . . . . . . 16 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 84 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 85 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 86 7.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 The Internet is successful in no small part because of its purposeful 93 avoidance of any single controlling entity. While originally this 94 may have been due to a desire to prevent a single technical failure 95 from having wide impact, it has also enabled the rapid adoption and 96 broad spread of the Internet, because internetworking does not 97 require obtaining permission from or ceding control to another entity 98 -- thereby accommodating a spectrum of requirements and positioning 99 the Internet as a public good. 101 As a result, Internet protocols share a common design goal: avoiding 102 centralization, which we define as the ability of a single person, 103 company, or government -- or a small group of them -- to observe, 104 control, or extract rent from the protocol's operation or use. 106 At the same time, the utility of many Internet protocols is enabled 107 or significantly enhanced by ceding some aspect of communication 108 between two parties to a third party -- often, in a manner that has 109 centralization risk. For example, there might be a need for a 110 'single source of truth' or a rendezvous facility to allow endpoints 111 to find each other. How should such protocols be designed? 113 Furthermore, many successful proprietary protocols and applications 114 on the Internet are de facto centralized. Some have become so well- 115 known that they are commonly mistaken for the Internet itself. In 116 other cases, Internet protocols seem to favour centralized 117 deployments due to economic and social factors. Should standards 118 efforts attempt to mitigate centralization in these cases, and if so, 119 how? 121 Finally, some autonomous networks have requirements to control the 122 operation of Internet protocols internally, and some users or groups 123 of users might cede control of some aspect of how they use the 124 Internet to a central authority, either voluntarily or under legal 125 compulsion. In both of these cases, should Internet protocols 126 accommodate such requirements, and if so, how? 127 This document discusses aspects of centralization with regard to 128 Internet protocol design (note that 'protocol' is used somewhat 129 loosely here, to also encompass what could be considered an 130 application). Section 2 explains why it is necessary for Internet 131 protocols to avoid centralization when possible. Section 3 surveys 132 the different kinds of centralization that Internet protocols might 133 be involved in. Section 4 then catalogues current high-level 134 approaches to mitigating centralization and discusses their 135 limitations. Finally, Section 5 discusses cross-cutting interactions 136 between centralization and protocol design, recommending best 137 practices where appropriate. 139 Engineers who design and standardize Internet protocols are the 140 primary audience for this document. However, designers of 141 proprietary protocols can benefit from considering aspects of 142 centralization, especially if they intend their protocol to be 143 considered for standardisation. Likewise, policymakers can use this 144 document to help identify and remedy inappropriately centralized 145 protocols and applications. 147 1.1. Notational Conventions 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 2. Why Avoid Centralization 157 Centralization is undesirable in the design of Internet protocols for 158 many reasons -- in particular, because it is counter to the nature of 159 the Internet, because it violates the purpose of the Internet from 160 the perspective of its end users, and because of the many negative 161 effects it can have on the networks operation and evolution. 163 By its very nature, the Internet must avoid centralization. As a 164 'large, heterogeneous collection of interconnected systems' [BCP95] 165 the Internet is often characterised as a 'network of networks'. As 166 such, these networks relate as peers who agree to facilitate 167 communication, rather than having a relationship of subservience to 168 others' requirements or coercion by them. 170 However, many Internet protocols allow a third party to be interposed 171 into communication between two other parties. In some cases, this is 172 not intended by the protocol's designers; for example, intervening 173 networks have taken advantage of unencrypted deployment of HTTP 174 [HTTP] to interpose 'interception proxies' (also known as 175 'transparent proxies') to cache, filter, track, or change traffic. 176 In cases where interposition of a third party is a designed feature 177 of the protocol, it is often characterised as _intermediation_, and 178 is typically used to help provide the protocol's functions -- 179 sometimes including those that are necessary for it to operate. 181 Whether or not interposition of a third party into communication is 182 intentional, the 'informational and positional advantages' 183 [INTERMEDIARY-INFLUENCE] gained can be used to observe behavior (the 184 'panopticon effect') and shape or even deny behaviour (the 185 'chokepoint effect') -- which can be used those parties (or the 186 states that have authority over them) for coercive ends. 187 [WEAPONIZED-INTERDEPENDENCE] 189 As Internet protocols' first duty is to the end user [RFC8890], 190 allowing such power to be concentrated into few hands is counter to 191 the IETF's mission of creating an Internet that 'will help us to 192 build a better human society.' [BCP95] 194 Additionally, concentration of power has deleterious effects on the 195 Internet itself, including: 197 * _Limiting Innovation_: Centralization can preclude the possibility 198 of 'permissionless innovation' -- the ability to deploy new, 199 unforeseen applications without requiring coordination with 200 parties other than those you are communicating with. 202 * _Constraining Competition_: The Internet and its users benefit 203 from robust competition when applications and services are 204 available from many different providers -- especially when those 205 users can build their own applications and services based upon 206 interoperable standards. When dependencies are formed on a 207 centralized service or platform, it effectively becomes an 208 essential facility, which encourages abuse of power. 210 * _Reducing Availability_: The Internet's availability (as well as 211 applications and services built upon it) improves when there are 212 many ways to obtain access to it. While centralized services 213 typically benefit from the focused attention that their elevated 214 role requires, when they do fail the resulting loss of 215 availability can have disproportionate impact. 217 * _Creating Monoculture_: At the scale available to a centralized 218 service or application, minor flaws in features such as 219 recommendation algorithms can be magnified to a degree that can 220 have broad (even societal) consequences. Diversity in these 221 functions is significantly more robust, when viewed systemically. 222 [POLYCENTRIC] 224 * _Self-Reinforcement_: As widely noted (see, eg., [ACCESS]), a 225 centralized service benefits from access to data which can be used 226 to further improve its offerings, while denying such access to 227 others. 229 To summarize, we avoid centralization because it would allow the 230 Internet (or some part of it) to be captured, effectively turning it 231 into a 'walled garden' that fails to meet both architectural design 232 goals and users' expectations, while endangering the viability of the 233 Internet at the same time. 235 3. Kinds of Centralization 237 Not all centralization of Internet protocols is equal; there are 238 several different types, each with its own properties. The 239 subsections below list some. 241 3.1. Direct Centralization 243 The most straightforward kind of centralized protocol creates a fixed 244 role for a specific party. 246 For example, most proprietary messaging, videoconferencing, chat, and 247 simliar protocols operate in this fashion. 249 While it has been argued that such protocols are simpler to design, 250 more amenable to evolution, and more likely to meet user 251 needs,[MOXIE] this approach most often reflects commercial goals -- 252 in particular, a strong desire to capture the financial benefits of 253 the protocol by 'locking in' users to a proprietary service. 255 Directly centralised protocols and applications are not considered to 256 be part of the Internet per se; instead, they are more properly 257 characterized as proprietary protocols that are built on top of the 258 Internet. As such, they are not regulated by the Internet 259 architecture or standards, beyond the constraints that the underlying 260 protocols (e.g., TCP, IP, HTTP) impose. 262 3.2. Necessary Centralization 264 Some protocols require the introduction of centralization risk that 265 is unavoidable by nature. 267 For example, when there is a need a single, globally coordinated 268 'source of truth', that facility is by nature centralized. The most 269 obvious instance is seen in the Domain Name System (DNS), which 270 allows human-friendly naming to be converted into network addresses 271 in a globally consistent fashion. 273 Allocation of IP addresses is another example of a necessary facility 274 being a centralization risk. Internet routing requires addresses to 275 be allocated uniquely, but if the addressing function were captured 276 by a single government or company, the entire Internet would be at 277 risk of abuse by that entity. 279 Similarly, the need for coordination in the Web's trust model brings 280 centralization risk, because a Certificate Authority (CA) can control 281 communication between the Web sites that they sign certificates for 282 and users whose browsers trust the CA's root certificates. 284 Protocols that need to solve the 'rendezvous problem' to coordinate 285 communication between two parties that are not in direct contact also 286 suffer from this kind of centralization risk. For example, chat 287 protocols need a way to coordinate communication between two parties 288 that wish to talk; while the actual communication can be direct 289 between them (so long as the protocol facilitates that), the 290 endpoints' mutual discovery typically requires a third party. 292 Internet protocols currently tend to mitigate necessary 293 centralization using measures such as mandated federation Section 4.1 294 and multi-stakeholder administration Section 4.2. 296 3.3. Indirect Centralization 298 Even when a protocol avoids direct centralization and does not 299 exhibit any necessary centralization, it might become centralized in 300 practice when external factors influence its deployment. 302 Indirect centralization can be caused by factors that encourage use 303 of a central facility despite the absence of such a requirement in 304 the protocol itself. Such factors might be economic, social, or 305 legal. 307 For example, cloud computing is used to deploy many Internet 308 protocols. Although the base concepts and control protocols for it 309 avoid centralization in the sense that there is no need for a single, 310 central cloud provider, the economics of providing compute at scale 311 as well as some social factors regarding developer familiarity and 312 comfort encourage convergence on a small number of cloud providers. 314 Often, the factors driving indirect centralization are related to the 315 network effects that are so often seen on the Internet. While in 316 theory every node on the Internet is equal, in practice some nodes 317 are much more connected than others: for example, just a few sites 318 drive much of the traffic on the Web. While expected and observed in 319 many kinds of networks [SCALE-FREE], network effects award asymmetric 320 power to nodes that act as intermediaries to communication. 322 Left unchecked, these factors can cause a potentially decentralized 323 application to become directly centralised, because the central 324 facility has leverage to 'lock in' users. For example, social 325 networking is an application that is currently supplied by a small 326 number of directly centralized, proprietary platforms despite 327 standardization efforts (see, e.g., 328 [W3C.CR-activitystreams-core-20161215]), due to the powerful network 329 effects associated. 331 By its nature, indirect centralization is difficult to avoid in 332 protocol design, and federated protocols are particularly vulnerable 333 to it (see Section 4.1). 335 3.4. Inherited Centralization 337 Most Internet protocols depend on other, 'lower-layer' protocols. 338 The features, deployment, and operation of these dependencies can 339 surface centralization risk into protocols operating 'on top' of 340 them. 342 For example, the network between endpoints can introduce 343 centralization risk to application-layer protocols, because it is 344 necessary for communication and therefore has power over it. A given 345 network might block access to, slow down, or modify the content of 346 various application protocols or specific services for financial, 347 political, operational, or criminal reasons, thereby creating 348 pressure to use other services, which can in turn result in 349 centralization. 351 Inherited centralization risk is only present when users cannot use 352 an alternative means of accessing the desired service. For example, 353 users often have flexibility in choice of Internet access, so they 354 could just 'route around' a network that impacts their chosen 355 service. However, such choices are often not available in the 356 moment, and the Internet's topology means that a 'choke point' 357 upstream could still affect their Internet access. 359 Usually, inherited centralization -- both existing and anticipated -- 360 is a factor to work around in protocol design, just as any other 361 constraint would be. One effective tool for doing so is encryption, 362 discussed further in Section 5.2. 364 3.5. Platform Centralization 366 The complement to inherited centralization is platform centralization 367 -- where a protocol does not directly define a central role, but 368 could facilitate centralization in the applications it supports. 370 For example, HTTP [HTTP] in itself is not considered a centralized 371 protocol; interoperable servers are relatively easy to instantiate, 372 and multiple clients are available. It can be used without central 373 coordination beyond that provided by DNS, as discussed above. 375 However, applications built on top of HTTP (as well as the rest of 376 the 'Web Platform') often exhibit centralization. As such, HTTP is 377 an example of a platform for centralization -- while the protocol 378 itself is not centralized, it does facilitate the creation of 379 centralized services and applications. 381 Like indirect centralization, platform centralization is difficult to 382 completely avoid in protocol design. Because of the layered nature 383 of the Internet, most protocols are designed to allow considerable 384 flexibility in how they are used, often in a way that it becomes 385 attractive to form a dependency on one party's operation. Notably, 386 this can happen even if the protocol does not accommodate 387 intermediation explicitly. 389 4. The Limits of Decentralization 391 4.1. Federation isn't Enough 393 A widely known technique for avoiding centralization in Internet 394 protocols is federation - that is, designing them in such a way that 395 new instances of any intermediary or otherwise centralized function 396 are relatively easy to create, and they are able to maintain 397 interoperability and connectivity with other instances. 399 For example, SMTP [RFC5321] is the basis of the e-mail suite of 400 protocols, which has two functions that are necessarily centralized: 402 1. Giving each user a globally unique address, and 404 2. Routing messages to the user, even when they change network 405 locations or are disconnected for long periods of time. 407 E-mail reuses DNS to mitigating first risk (see Section 5.3). To 408 mitigate the second, it defines an intermediary role for routing 409 users' messages, the Message Transfer Agent (MTA). By allowing 410 anyone to deploy a MTA and defining rules for interconnecting them, 411 the protocol's users avoid the need for a single, central router. 413 Users can (and often do) choose to delegate that role to someone 414 else, or run their own MTA. However, running your own mail server 415 has become difficult, due to the likelihood of a small MTA being 416 classified as a spam source. Because large MTA operaters are widely 417 known and have greater impact if their operation is affected, they 418 are less likely to be classified as such, thereby indirectly 419 centralizing the protocol's operation (see Section 3.3). 421 This illustrates that while federation can be effective at avoiding 422 direct centralization and managing necessary centralization, 423 federated protocols are still vulnerable to indirect centralization, 424 and may exhibit platform centralization. 426 Another example of a federated Internet protocol is XMPP [RFC6120], 427 supporting 'instant messaging' and similar functionality. Like 428 e-mail, it reuses DNS for naming and requires federation to 429 facilitate rendezvous of users from different systems. 431 While some deployments of XMPP do support truly federated messaging 432 (i.e., a person using service A can interoperably chat with someone 433 using service B), many of the largest do not. Because federation is 434 voluntary, some operators made a decision to capture their users into 435 a single service, rather than provide the benefits of global 436 interoperability. 438 The examples above show that federation can be a useful technique to 439 avoid direct centralization, but on its own is not sufficient to 440 avoid indirect centralization. If the value provided by a protocol 441 can be captured by a single entity, they may use the protocol as a 442 platform to obtain a 'winner take all' outcome -- a significant risk 443 with many Internet protocols, since network effects often promote 444 such outcomes. Likewise, external factors (such as spam control) 445 might naturally 'tilt the table' towards a few operators of these 446 protocols. 448 4.2. Multi-Stakeholder Administration is Hard 450 Delegating the administration of a necessarily centralized function 451 (see Section 3.2) to a multi-stakeholder body is an onerous but 452 sometimes necessary way to mitigate the undesirable effects. 454 A multi-stakeholder body is an institution that includes 455 representatives of the different kinds of parties that are affected 456 by the system's operation ('stakeholders') in an attempt to make 457 well-reasoned, broadly agreed-to, and authoritative decisions. 459 The most relevant example of this technique is the administration of 460 the Domain Name System [RFC1035], which as a 'single source of truth' 461 requires centralization of the naming function. To mitigate 462 centralization, this task is carried out by multiple root servers 463 that are administered by separate operators -- themselves diverse in 464 geography and a selection of corporate entities, non-profits and 465 government bodies from many jurisdictions and affiliations. 466 Furthermore, those operators are regulated by ICANN 467 (https://www.icann.org/resources/pages/governance/governance-en), 468 which is defined as a globally multi-stakeholder body with 469 representation from a end users, governments, operators, and others. 471 Another example of multi-stakeholderism is the standardization of 472 Internet protocols themselves. Because a specification effectively 473 controls the behavior of implementations that are conformant with it, 474 the standardization process can be seen as a single point of control. 475 As a result, Internet standards bodies like the IETF allow open 476 participation and contribution, make decisions in an open and 477 accountable way, have a well-defined process for making (and when 478 necessary, appealing) decisions, and take into account the views of 479 different stakeholder groups [RFC8890]. 481 Yet another example is the administration of the Web's trust model, 482 implemented by Web browsers as relying parties and Certificate 483 Authorities as trust anchors. To assure that all parties meet the 484 operational and security requirements necessary to provide the 485 desired properties, the CA/Browser Forum (https://cabforum.org) was 486 established as an oversight body that involves both of those parties 487 as stakeholders. 489 In each of these examples, setup and ongoing operation of a multi- 490 stakeholder organization is not trivial. This is the major downside 491 of such an approach. Additionally, the legitimacy of such an 492 organization cannot be assumed, and may be difficult to establish and 493 maintain (see, eg, [LEGITIMACY-MULTI]). This concern is especially 494 relevant if the function being coordinated is broad, complex, and/or 495 contentious. 497 4.3. Blockchains Are Not Magical 499 Increasingly, distributed consensus technologies such as the 500 blockchain are touted as a solution to centralization issues. A 501 complete survey of this rapidly-changing area is beyond the scope of 502 this document, but at a high level, we can generalise about their 503 properties. 505 These techniques avoid centralization risk by distributing 506 intermediary or otherwise potentially centralized functions to 507 members of a large pool of protocol participants. Verification of 508 proper performance of a function is typically guaranteed using 509 cryptographic techniques (often, an append-only transaction ledger). 510 The assignment of a particular task to a node for handling usually 511 cannot be predicted or controlled. To assure diversity in the pool 512 of participants (thereby preventing Sybil attacks), techniques such 513 as proof-of-work (where each participant has to demonstrate 514 significant consumption of resources) or proof-of-stake (where each 515 participant has some other incentive to execute correctly) are used. 517 As such, these techniques purposefully disallow direct centralization 518 and are robust against inherited centralization. Depending upon the 519 application in question, indirect and platform centralization may 520 still be possible, but in general these techniques do not lend 521 themselves to these ends as readily as federated systems do. 523 However, distributed consensus technologies have several potential 524 shortcomings that may make them inappropriate -- or at least 525 difficult to use -- for many Internet applications, because their use 526 conflicts with other important goals: 528 1. Distributed consensus protocols can have significant implications 529 for privacy. Because activity (such as queries or transactions) 530 are shared with many unknown parties, they have very different 531 privacy properties than traditional client/server protocols. 532 Mitigations (e.g., Private Information Retrieval; see, eg, [PIR]) 533 are still not suitable for broad deployment. 535 2. Their complexity and 'chattiness' typically results in 536 significantly less efficient use of the network. When 537 distributed consensus protocols use proof-of-work, energy 538 consumption can become significant (to the point where some 539 jurisdictions have banned its use). 541 3. Distributed consensus protocols are still not proven to scale to 542 the degree expected of successful Internet protocols. In 543 particular, relying on unknown third parties to deliver 544 functionality can introduce variability in latency, availability, 545 and throughput. This is a marked change for applications with 546 high expectations for these properties (e.g., commercial Web 547 services). 549 4. By design, distributed consensus protocols diffuse responsibility 550 for a function among several, difficult-to-identify parties. 551 While this may be an effective way to prevent many kinds of 552 centralization, it also means that making someone accountable for 553 how the function is performed is impossible, beyond the bounds of 554 the protocol's design. 556 It is also important to recognise that a protocol can use distributed 557 consensus for some functions, but still have centralization risk 558 elsewhere. Even when distributed consensus is used exclusively 559 (which is uncommon, due to the associated costs), some degree of 560 coordination is still necessary -- whether that be through governance 561 of the function itself, creation of shared implementations, or 562 documentation of shared wire protocols. That represents 563 centralization risk, just at a different layer (inherited or 564 platform, depending on the circumstances). 566 These potential shortcomings do not rule out the use of distributed 567 consensus technologies for every use case. They do, however, caution 568 against relying upon these technologies uncritically. 570 5. Guidelines for Protocol Designers 572 While the following recommendations are not a complete guide, they 573 can be a starting point for avoiding or mitigating centralization in 574 Internet protocols. 576 5.1. Allow Intermediation Sparingly 578 The introduction of an intermediary role -- i.e., one that performs a 579 function but is not a first party to communication -- adds 580 centralization risk to Internet protocols, because it brings 581 opportunities for control and observation. Even when the protocol is 582 federated (see Section 4.1) to avoid direct centralization, 583 significant indirect centralization risks exist when intermediation 584 is allowed. 586 However, intermediation can sometimes add significant value to a 587 protocol, or enable what is considered a necessary function. In such 588 cases, the centralized function SHOULD be as minimal as possible, and 589 expose only the information and pontential for control necessary for 590 that function to be performed. Protocol designers SHOULD consider 591 the likely deployment patterns for those intermediaries and how 592 network effects and other factors will influence them. 594 Such predictions can be difficult. For example, an intermediary 595 interposed by the end user of a protocol might allow them to delegate 596 functions to a party they trust, thereby empowering them. However, 597 if an intervening network is able to force users to delegate to a 598 particular intermediary, inherited centralization could result. 600 When carefully considered, intermediation can be a powerful way to 601 enforce functional boundaries -- for example, to reduce the need for 602 users to trust potentially malicious endpoints, as seen in the so- 603 called 'oblivious' protocols currently in development (e.g., 604 [I-D.pauly-dprive-oblivious-doh]) that allow end users to hide their 605 identity from services, while still accessing them. 607 The same advice applies in these cases; the observation and control 608 potential SHOULD be as minimal as possible, while still meeting the 609 design goals of the protocol. 611 See [I-D.thomson-tmi] for more guidance. 613 5.2. Encrypt, Always 615 When deployed at scale, encryption can be an effective technique to 616 reduce many inherited centralization risks. By reducing the number 617 of parties who have access to content of communication, the ability 618 of lower-layer protocols and intermediaries at those layers to 619 interfere with or observe is precluded. Even when they can still 620 prevent communication, the use of encryption makes it more difficult 621 to discriminate the target from other traffic. 623 Note that the benefits are most pronounced when the majority (if not 624 all) traffic is encrypted. As a result, protocols SHOULD be 625 encrypted by default. 627 See also [RFC7258]. 629 5.3. Reuse Existing Tools 631 When a protocol function has necessary centralization risk and there 632 exists an already-deployed solution with appropriate mitigations, 633 that solution should be reused in favour of inventing a new one. 635 For example, if a protocol requires a coordinated, global naming 636 function, reusing the Domain Name System is preferable to 637 establishing a new system, because its centralization risk is known 638 and understood (see Section 4.2). 640 5.4. Accomodate Limited Domains Warily 642 [RFC8799] explores a class of protocols that operate in 'limited 643 domains' -- that is, they are not intended to be 'full' Internet 644 protocols with broad applicability, but instead operation within a 645 particular network or other constrained environment. 647 Often, limited-domain protocols address network requirements -- for 648 example, imposing security policy, integrating services or 649 application functions into the network, or differentiating different 650 classes of network services. 652 Such network-centric requirements can introduce the risk of inherited 653 centralization when they allow the network to interpose itself and 654 its requirements between the endpoints of a given communication. 656 These risks can be partially mitigated by requiring such functions to 657 be opted into by one or both endpoints (once both the network and the 658 endpoint are authenticated to each other), so that the network is 659 acting on their behalf. However, this approach is still vulnerable 660 to indirect centralization, because the endpoints may be pressured to 661 acquiesce to a network's demands. 663 5.5. Target Extensibility 665 An important feature of Internet protocols is their ability to evolve 666 over time, so that they can meet new requirements and adapt to new 667 conditions without requiring a 'flag day' to convert users. 668 Typically, protocol evolution is accommodated through extension 669 mechanisms, where optional features can be added over time in an 670 interoperable fashion. 672 Protocol extensions can bring risk of platform centralization if a 673 powerful entity can change the target for meaningful interoperability 674 by adding proprietary extensions to a standard protocol. This is 675 especially true when the core standard does not itself provide 676 sufficient utility to be appealing on its own. 678 For example, the SOAP protocol [SOAP] was an extremely flexible 679 framework, allowing vendors to attempt to capture the market by 680 requiring use of their preferred extensions to interoperate. 682 This kind of centralization risk can be mitigated in a few ways. 683 First and foremost, Internet protocols SHOULD provide concrete 684 utility to the majority of their users as published; 'framework' 685 standards facilitate this kind of risk. 687 Furthermore, Internet protocols SHOULD NOT make every aspect of their 688 operation extensible; extension points SHOULD be reasoned, 689 appropriate boundaries for flexibility and control. When extension 690 points are defined, they SHOULD NOT allow an extension to declare 691 itself to be mandatory-to-interoperate, as that pattern invites 692 abuse. 694 5.6. Acknowledge the Limits of Protocol Design 696 Centralization cannot be prevented through protocol design and 697 standardization efforts alone. While the guidelines above may 698 forestall some types of centralization, indirect and platform 699 centralization are often outside the control of a protocol's 700 architecture. 702 Thankfully, architecture is not the only form of regulation; legal 703 mechanisms combined with changing norms and the resulting market 704 forces have their own regulatory effects. [NEW-CHICAGO] 706 In this view, the job of a protocol designer is to avoid 707 centralization with architecture where possible, but where it is not, 708 to create affordances for these other regulating forces. 710 6. Security Considerations 712 This document does not have direct security impact on Internet 713 protocols. However, failure to consider centralization risks might 714 result in a myriad of security issues. 716 7. References 718 7.1. Normative References 720 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 721 Requirement Levels", BCP 14, RFC 2119, 722 DOI 10.17487/RFC2119, March 1997, 723 . 725 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 726 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 727 May 2017, . 729 7.2. Informative References 731 [ACCESS] Vestager, M., "Defending Competition in a Digitised World, 732 Address at the European Consumer and Competition Day", 733 April 2019, . 738 [BCP95] Alvestrand, H., "A Mission Statement for the IETF", 739 BCP 95, RFC 3935, October 2004. 741 743 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 744 Semantics", Work in Progress, Internet-Draft, draft-ietf- 745 httpbis-semantics-19, 12 September 2021, 746 . 749 [I-D.pauly-dprive-oblivious-doh] 750 Kinnear, E., McManus, P., Pauly, T., Verma, T., and C. A. 751 Wood, "Oblivious DNS Over HTTPS", Work in Progress, 752 Internet-Draft, draft-pauly-dprive-oblivious-doh-08, 3 753 December 2021, . 756 [I-D.thomson-tmi] 757 Thomson, M., "Principles for the Involvement of 758 Intermediaries in Internet Protocols", Work in Progress, 759 Internet-Draft, draft-thomson-tmi-02, 6 July 2021, 760 . 763 [INTERMEDIARY-INFLUENCE] 764 Judge, K., "Intermediary Influence", 2014, 765 . 768 [LEGITIMACY-MULTI] 769 Palladino, N. and N. Santaniello, "Legitimacy, Power, and 770 Inequalities in the Multistakeholder Internet Governance", 771 2020. 773 [MOXIE] Marlinspike, M., "Reflections: The ecosystem is moving", 774 May 2016, 775 . 777 [NEW-CHICAGO] 778 Lessig, L., "The New Chicago School", June 1998. 780 [PIR] Olumofin, F. and I. Goldberg, "Revisiting the 781 Computational Practicality of Private Information 782 Retrieval", 2010. 784 [POLYCENTRIC] 785 Aligia, P.D. and V. Tarko, "Polycentricity: From Polanyi 786 to Ostrom, and Beyond", April 2012. 788 [RFC1035] Mockapetris, P., "Domain names - implementation and 789 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 790 November 1987, . 792 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 793 DOI 10.17487/RFC5321, October 2008, 794 . 796 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 797 Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, 798 March 2011, . 800 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 801 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 802 2014, . 804 [RFC8799] Carpenter, B. and B. Liu, "Limited Domains and Internet 805 Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020, 806 . 808 [RFC8890] Nottingham, M., "The Internet is for End Users", RFC 8890, 809 DOI 10.17487/RFC8890, August 2020, 810 . 812 [SCALE-FREE] 813 Albert, R., "Emergence of Scaling in Random Networks", 814 October 1999, . 816 [SOAP] Mitra, N. and Y. Lafon, "SOAP Version 1.2 Part 0: Primer 817 (Second Edition)", World Wide Web Consortium 818 Recommendation REC-soap12-part0-20070427, 27 April 2007, 819 . 821 [W3C.CR-activitystreams-core-20161215] 822 Snell, J. and E. Prodromou, "Activity Streams 2.0", World 823 Wide Web Consortium CR CR-activitystreams-core-20161215, 824 15 December 2016, . 827 [WEAPONIZED-INTERDEPENDENCE] 828 Farrell, H. and A.L. Newman, "Weaponized Interdependence: 829 How Global Economic Networks Shape State Coercion", 2019, 830 . 832 Appendix A. Acknowledgements 834 This document benefits from discussions with Brian Trammell during 835 our shared time on the Internet Architecture Board. 837 Author's Address 839 Mark Nottingham 840 Prahran 841 Australia 843 Email: mnot@mnot.net 844 URI: https://www.mnot.net/