wdiff draft-nottingham-avoiding-internet-centralization-00.txt draft-nottingham-avoiding-internet-centralization-01.txt

Network Working Group M. Nottingham
Internet-Draft 8 December 2021 9 January 2022
Intended status: Informational
Expires: 11 June 13 July 2022

Avoiding Internet

Centralization
draft-nottingham-avoiding-internet-centralization-00 and Internet Standards
draft-nottingham-avoiding-internet-centralization-01

Abstract

Avoiding centralization is an important goal for

Despite being designed and operated as a decentralized network-of-
networks, the Internet protocols. is continuously subjected to forces that
encourage centralization.

This document offers a definition of centralization, discusses explains why it
is necessary for Internet protocol designers to consider its risks, undesirable, identifies different kinds types of centralization,
catalogues some limitations of current common approaches to controlling it, and recommends
best practices for protocol designers.
explores what Internet standards efforts can do to address it.

About This Document

This note is to be removed before publishing as an RFC.

Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-nottingham-avoiding-internet-
centralization/.

Source for this draft and an issue tracker can be found at
https://github.com/mnot/avoiding-internet-centralization.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 June 13 July 2022.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions 2
2. What is Centralization . . . . . . . . . . . . . . . . . 4
2. . . 3
3. Why Avoid Centralization . . . . . . . . . . . . . . . . . . 4
3.
4. Kinds of Centralization . . . . . . . . . . . . . . . . . . . 6
3.1.
4.1. Direct Centralization . . . . . . . . . . . . . . . . . . 6
3.2.
4.2. Necessary Centralization . . . . . . . . . . . . . . . . 6
3.3.
4.3. Indirect Centralization . . . . . . . . . . . . . . . . . 7
3.4.
4.4. Inherited Centralization . . . . . . . . . . . . . . . . 8
3.5.
4.5. Platform Centralization . . . . . . . . . . . . . . . . . 8
4. 9
5. The Limits of Decentralization . . . . . . . . . . . . . . . 9
4.1.
5.1. Federation isn't Enough . . . . . . . . . . . . . . . . . 9
4.2. 10
5.2. Multi-Stakeholder Administration is Hard . . . . . . . . 10
4.3. 11
5.3. Blockchains Are Not Magical . . . . . . . . . . . . . . . 11
5. Guidelines for Protocol Designers . . . . . . . . . . . . . . 13
5.1. Allow Intermediation Sparingly 12
6. What Should Internet Standards Do? . . . . . . . . . . . . . 13
5.2. Encrypt, Always . . . . . . . . . . . . . . . . . . . . . 14
5.3. Reuse Existing Tools . . . . . . . . . . .
6.1. Manage Centralization Risk Where Effective . . . . . . . 14
5.4. Accomodate Limited Domains Warily . . . . . . . . . . .
6.2. Create Standards to Decentralize Proprietary Functions . 15
5.5. Target Extensibility . .
6.3. Limit Intermediary Power . . . . . . . . . . . . . . . . 15
5.6. Acknowledge the Limits of Protocol Design . . . . . . . . 16
6. Security Considerations . . .
6.4. Avoid Over-Extensibility . . . . . . . . . . . . . . . . 16
7. References . . . . . . Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Normative 17
8. Informative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16 17
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 20

1. Introduction

The Internet is successful has succeeded in no small part because of its purposeful
avoidance of any single controlling entity. While originally this approach may have been due to
reflect a desire to prevent a single technical failure from having
wide impact, impact,[RAND] it has also enabled the Internet's rapid adoption
and broad spread of the Internet, spread, because internetworking does did not require obtaining
permission from or ceding control to another entity -- thereby
accommodating a spectrum of requirements and positioning the Internet
as a public good.

As a result, Internet protocols share a common design goal:

While avoiding
centralization, which we define as the ability of a single person,
company, or government -- or a small group of them -- to observe,
control, or extract rent from the protocol's operation or use.

At the same time, the utility of many Internet protocols centralization is enabled
or significantly enhanced by ceding some aspect of communication
between two parties to a third party -- often, in a manner widely shared goal for the
Internet, meeting that goal has
centralization risk. For example, there might be a need for a
'single source of truth' or a rendezvous facility to allow endpoints
to find each other. How should such protocols be designed?

Furthermore, many proven difficult. Many successful proprietary
protocols and applications on the Internet today are de facto centralized. Some designed or
operated in a centralized fashion -- to the point where some
proprietary, centralized services have become so well-
known well-known that they
are commonly mistaken for the Internet itself. In
other cases, Internet Even when protocols seem to favour centralized
deployments due
incorporate techniques intended to prevent centralization, economic
and social factors. Should standards
efforts attempt to mitigate centralization in these cases, and if so,
how?

Finally, some autonomous networks have requirements to control the
operation of Internet protocols internally, and some users or groups
of factors can drive users might cede control of some aspect of how they use the
Internet to a central authority, either voluntarily prefer centralized solutions
built with or under legal
compulsion. In both on top of these cases, should Internet protocols
accommodate supposedly decentralized technology.

These difficulties call into question what role architectural
regulation -- in particular, open standards bodies such requirements, as at the
IETF -- should be play in preventing, mitigating, and if so, how? controlling
centralization of the Internet.

This document discusses aspects of centralization with regard to
Internet protocol design (note that 'protocol' is used somewhat
loosely here, relate to also encompass what could be considered an
application).
Internet standards efforts. Section 2 provides a definition of
centralization. Section 3 explains why it is necessary for Internet
protocols to avoid centralization when possible. of Internet's
functions is undesirable. Section 3 4 surveys the different kinds of
centralization that Internet protocols might
be involved in. surface on the Internet. Section 4 5 then
catalogues current high-level approaches to mitigating centralization and
discusses their limitations. Finally, Section 5 discusses cross-cutting interactions
between 6 considers the role
that Internet standards play in avoiding centralization and protocol design, recommending best
practices where appropriate.
mitigating its effects.

Engineers who design and standardize Internet protocols are the
primary audience for this document. However, designers of
proprietary protocols can benefit from considering aspects of
centralization, especially if they intend their protocol to be
considered for eventual standardisation. Likewise, policymakers can
use this document to help identify and remedy inappropriately
centralized protocols and applications.

1.1. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this

2. What is Centralization

This document defines "centralization" as the ability of a single
entity (e.g., a person, company, or government) -- or a small group
of them -- to observe, control, or extract rent from the operation or
use of a given function on the Internet.

Here, "function" is defined broadly. It might be an enabling
protocol already defined by standards, such as IP [RFC791], BGP
[RFC4271], TCP [RFC793], or HTTP [HTTP]. It might also be a proposal
for a new enabling protocol, or an extension to an existing one.

However, centralization is not limited to standards-defined
protocols. User-visible applications built on top of the functions
provided by standards are also vulnerable to centralization -- for
example, social networking, file sharing, financial services, and
news dissemination. Likewise, the supply of hardware, operating
systems, and software can exhibit centralization.

Centralization risk is strongest when it necessarily affects the
entire Internet. However, it can also be present when a substantial
portion of the Internet's users lack options for a given function.
For example, if there is only one provider a function in a given
region or legal jurisdiction, that function is effectively
centralized for those users.

"Decentralization" is the process of identifying centralization risk
in the functions of a protocol or application, followed by
application of appropriate techniques to prevent or mitigate
centralization.

Decentralization does not require that a given function need be interpreted so
widely distributed that other important factors, such as described efficiency,
resiliency, latency, or availability are sacrificed. In some cases,
a function that is only available through a relatively small number
of providers can be effectively decentralized, given the appropriate
circumstances (see, for example, the DNS).

Therefore, discussions of centralization and architectural efforts at
decentralization need to be made on a case-by-base basis, depending
on the function in BCP
14 [RFC2119] [RFC8174] when, question, surrounding circumstances, and other
regulatory mechanisms.

Note that it is important to distinguish centralization from anti-
competitive concerns (also known as "anti-trust"). While there are
many interactions between them and making the Internet more
competitive may be a motivation for avoiding centralization, only when, they appear
courts are authoritative in all
capitals, as shown here.

2. determining what is and is not anti-
competitive in a given market, not standards bodies and other
technical fora.

3. Why Avoid Centralization

Centralization is undesirable in the design of Internet protocols for
many reasons -- in particular, because it is counter to the nature of
the Internet, because it violates the purpose of the Internet from
the perspective of its end users, users' expectations, and
because of the many negative effects it can have on the networks
operation and evolution.

By its very nature,

Firstly, the Internet must avoid centralization. Internet's very nature is incompatible with
centralization of its functions. As a 'large, heterogeneous
collection of interconnected systems' [BCP95] the Internet is often
characterised as a 'network of networks'. As such, these networks
relate as peers who agree to facilitate communication, rather than
having a relationship of subservience to others' requirements or
coercion by them.

However, many Internet protocols allow a third party to be interposed
into communication between two other parties. In some cases, this is
not intended by the protocol's designers; for example, intervening
networks have taken advantage of unencrypted deployment of HTTP
[HTTP] to interpose 'interception proxies' (also known

Secondly, as
'transparent proxies') to cache, filter, track, or change traffic.
In cases where interposition of a third party is a designed feature
of the protocol, it Internet's first duty is often characterised as _intermediation_, and to the end user [RFC8890],
allowing such power to be concentrated into few hands is typically used counter to help provide
the protocol's functions --
sometimes including those IETF's mission of creating an Internet that are necessary for it 'will help us to operate.

Whether or not interposition of
build a better human society.' [BCP95] When a third party into communication is
intentional, has
unavoidable access to communications, the 'informational and
positional advantages' [INTERMEDIARY-INFLUENCE] gained can be used to
observe behavior (the 'panopticon effect') and shape or even deny
behaviour (the 'chokepoint effect') -- which can be used by those
parties (or the states that have authority over them) for coercive
ends. [WEAPONIZED-INTERDEPENDENCE]

As Internet protocols' first duty is to the end user [RFC8890],
allowing such power to be concentrated into few hands is counter to
the IETF's mission of creating an Internet that 'will help us to
build a better human society.' [BCP95]

Additionally,

Finally, concentration of power has deleterious effects on the
Internet itself, including:

* _Limiting Innovation_: Centralization can preclude the possibility
of 'permissionless innovation' -- the ability to deploy new,
unforeseen applications without requiring coordination with
parties other than those you are communicating with.

* _Constraining Competition_: The Internet and its users benefit
from robust competition when applications and services are
available from many different providers -- especially when those
users can build their own applications and services based upon
interoperable standards. When dependencies are formed on a
centralized service or platform, it effectively becomes an
essential facility, which encourages abuse of power.

* _Reducing Availability_: The Internet's availability (as well as
applications and services built upon it) improves when there are
many ways to obtain access to it. While centralized services
typically benefit from the focused attention that their elevated
role requires, when they do fail the resulting loss of
availability can have disproportionate impact.

* _Creating Monoculture_: At the scale available to a centralized
service or application, minor flaws in features such as
recommendation algorithms can be magnified to a degree that can
have broad (even societal) consequences. Diversity in the
implementation of these functions is significantly more robust,
when viewed systemically. [POLYCENTRIC]

* _Self-Reinforcement_: As widely noted (see, eg., [ACCESS]), a
centralized service benefits from access to data which can be used
to further improve its offerings, while denying such access to
others.

See also [TECH-SUCCESS-FACTORS].

To summarize, we avoid centralization because it would allow the Internet (or some part
of it) to be captured, effectively turning it into a 'walled garden'
that fails to meet both architectural design goals and users'
expectations, while and endangering the its ongoing viability of the
Internet at the same time.

4. Kinds of Centralization

Not all centralization

Centralization of the Internet protocols is equal; there are
several different types, each with not uniform; it presents in a
variety of ways, depending on its own properties. relationship to the function in
question and underlying causes. The subsections below list some.

3.1. offer the
start of a classification system for Internet centralization.

4.1. Direct Centralization

The most straightforward kind of centralized protocol centralization creates a fixed role
for a specific party. For example, most proprietary messaging,
videoconferencing, chat, and
simliar similar protocols operate in this
fashion.

While it has been argued that such protocols are simpler to design,
more amenable to evolution, and more likely to meet user
needs,[MOXIE] needs
[MOXIE], this approach most often reflects commercial goals -- in
particular, a strong desire to capture the financial benefits of the
protocol by 'locking in' users to a proprietary service.

Directly centralised protocols and applications are not considered to
be part of the Internet per se; instead, they are more properly
characterized as proprietary protocols that are built on top of the
Internet. As such, they are not regulated by the Internet
architecture or standards, beyond the constraints that the underlying
protocols (e.g., TCP, IP, HTTP) impose.

3.2.

4.2. Necessary Centralization

Some protocols require the introduction of centralization risk that
is unavoidable by nature.

For example, when there is a need a single, globally coordinated
'source of truth', that facility function is by nature centralized. The most
obvious instance is seen in the Domain Name System (DNS), which
allows human-friendly naming to be converted into network addresses
in a globally consistent fashion.

Allocation of IP addresses is another example of a necessary facility function
being a centralization risk. Internet routing requires addresses to
be allocated uniquely, but if the addressing function were captured
by a single government or company, the entire Internet would be at
risk of abuse by that entity.

Similarly, the need for coordination in the Web's trust model brings
centralization risk, because a Certificate Authority (CA) can control
communication between the Web sites that they sign certificates for
and users whose browsers trust the CA's root certificates.

Protocols that need to solve the 'rendezvous problem' "rendezvous problem" to coordinate
communication between two parties that are not in direct contact also
suffer from this kind of centralization risk. For example, chat
protocols need a way to coordinate communication between two parties
that wish to talk; while the actual communication can be direct
between them (so long as the protocol facilitates that), the
endpoints' mutual discovery typically requires a third party.

Internet protocols currently tend often attempt to mitigate necessary centralization
risk using measures such as mandated federation Section 4.1 5.1 and
multi-stakeholder administration Section 4.2.

3.3. 5.2.

Because of the inherent risks and costs of these approaches,
functions that successfully use these techniques are often reused by
others with similar requirements. For example, if a protocol
requires a coordinated, global naming function, reusing the Domain
Name System is usually preferable to establishing a new system,
because its centralization risk is known and understood, and the
risks inherent in establishing new mitigations are avoided.

4.3. Indirect Centralization

Even when a protocol avoids direct centralization and does not
exhibit any necessary centralization, it might become centralized in
practice when external factors influence its deployment. Indirect
centralization can be caused by factors that encourage use of a
central facility function despite the absence of such a requirement in the
protocol itself. Such factors might be economic, social, or legal.

For example, cloud computing is used to deploy many Internet
protocols. Although the base concepts and control protocols for it
avoid centralization in the sense that there is no need for a single,
central cloud provider, the economics of providing compute at scale
as well as some social factors regarding developer familiarity and
comfort encourage convergence on a small number of cloud providers.

Often, the factors driving indirect centralization are related to the
network effects that are so often seen on the Internet. While in
theory every node on the Internet is equal, in practice some nodes
are much more connected than others: for example, just a few sites
drive much of the traffic on the Web. While expected and observed in
many kinds of networks [SCALE-FREE], network effects award asymmetric
power to nodes that act as intermediaries to communication.

Left unchecked, these factors can cause a potentially decentralized
application to become directly centralised, because the central
facility
function has leverage to 'lock in' "lock in" users. For example, social
networking is an application that is currently supplied by a small
number of directly centralized, proprietary platforms despite
standardization efforts (see, e.g.,
[W3C.CR-activitystreams-core-20161215]), due to the powerful network
effects associated.

By its nature, indirect centralization is difficult to avoid in
protocol design, and federated protocols are particularly vulnerable
to it (see Section 4.1).

3.4. 5.1).

4.4. Inherited Centralization

Most Internet protocols depend on other, 'lower-layer' "lower-layer" protocols.
The features, deployment, and operation of these dependencies can
surface centralization risk into protocols operating 'on top' functions and applications build "on
top" of them.

For example, the network between endpoints can introduce
centralization risk to application-layer protocols, because it is
necessary for communication and therefore has power over it. A given
network might block access to, slow down, or modify the content of
various application protocols or specific services for financial,
political, operational, or criminal reasons, thereby creating
pressure to use other services, which can in turn result in
centralization.
centralization of them.

Inherited centralization risk is only present when users cannot use
an alternative means of accessing the desired service. For example,
users often have flexibility in choice of Internet access, so they
could just 'route around' "route around" a network that impacts their chosen
service. However, such choices are often not available in the
moment, and the Internet's topology means that a 'choke point' choke point upstream
could still affect their Internet access.

Usually,

When deployed at scale, encryption can be an effective technique to
control many inherited centralization -- both existing risks. By reducing the number
of parties who have access to content of communication, the ability
of lower-layer protocols and anticipated -- intermediaries at those layers to
interfere with or observe is a factor precluded. Even when they can still
prevent communication, the use of encryption makes it more difficult
to work around in protocol design, just as any discriminate the target from other
constraint would be. One effective tool for doing so traffic.

Note that the prohibitive effect on inherited centralization is encryption,
discussed further in Section 5.2.

3.5. most
pronounced when most (if not all) traffic is encrypted -- providing
yet more motivation for that goal (see also [RFC7258]).

4.5. Platform Centralization

The complement to inherited centralization is platform centralization
-- where a protocol function does not directly define a central role, but
could facilitate centralization in the applications it supports.

For example, HTTP [HTTP] in itself is not considered a centralized
protocol; interoperable servers are relatively easy to instantiate,
and multiple clients are available. It can be used without central
coordination beyond that provided by DNS, as discussed above.

However, applications built on top of HTTP (as well as the rest of
the 'Web Platform') often exhibit centralization. As such, HTTP is
an example of a platform for centralization -- while the protocol
itself is not centralized, it does facilitate the creation of
centralized services and applications.

Like indirect centralization, platform centralization is difficult to
completely avoid in protocol design. Because of the layered nature
of the Internet, most protocols are designed to allow considerable
flexibility in how they are used, often in a way that it becomes
attractive to form a dependency on one party's operation. Notably,
this can happen even if the protocol does not accommodate
intermediation explicitly.

5. The Limits of Decentralization

4.1.

Over time, various techniques have been developed to decentralize
protocols and applications. While these approaches can be used to
create a function which is less centralized or less amenable to some
kinds of centralization, they are not adequate to completely avoid
centralization on their own. As such, while the use of these
techniques is often appropriate and sometimes effective, they are not
indicators of whether a protocol is centralized without further
analysis.

5.1. Federation isn't Enough

A widely known technique for avoiding managing centralization in Internet
protocols is federation - -- that is, designing them in such a way that
new instances of any intermediary or otherwise centralized function
are relatively easy to create, and they are able to maintain
interoperability and connectivity with other instances.

For example, SMTP [RFC5321] is the basis of the e-mail suite of
protocols, which has two functions that are necessarily centralized:

1. Giving each user a globally unique address, and

2. Routing messages to the user, even when they change network
locations or are disconnected for long periods of time.

E-mail reuses DNS to mitigating help mitigate the first risk (see Section 5.3). risk. To mitigate the
second, it defines an intermediary role for routing users' messages,
the Message Transfer Agent (MTA). By allowing anyone to deploy a MTA
and defining rules for interconnecting them, the protocol's users
avoid the need a requirement for a single, central router.

Users can (and often do) choose to delegate that role to someone
else, or run their own MTA. However, running your own mail server
has become difficult, due to the likelihood of a small MTA being
classified as a spam source. Because large MTA operaters are widely
known and have greater impact if their operation is affected, they
are less likely to be classified as such, thereby indirectly
centralizing the protocol's operation (see Section 3.3).

This illustrates that while federation can be effective at avoiding
direct centralization and managing necessary centralization,
federated protocols are still vulnerable to indirect centralization,
and may exhibit platform centralization. 4.3).

Another example of a federated Internet protocol is XMPP [RFC6120],
supporting 'instant messaging' "instant messaging" and similar functionality. Like
e-mail, it reuses DNS for naming and requires federation to
facilitate rendezvous of users from different systems.

While some deployments of XMPP do support truly federated messaging
(i.e., a person using service A can interoperably chat with someone
using service B), many of the largest do not. Because federation is
voluntary, some operators made a decision to capture their users into
a single service, rather than provide the benefits of global
interoperability.

The examples above show illustrate that federation can be a useful
technique to avoid direct centralization and manage necessary
centralization, but on its own is not sufficient to avoid indirect
and platform centralization. If the value provided by a protocol can
be captured by a single entity, they may use the protocol as a
platform to obtain a 'winner take all' outcome -- a significant risk
with many Internet protocols, since network effects often promote
such outcomes. Likewise, external factors (such as spam control)
might naturally 'tilt the table' towards a few operators of these
protocols.

4.2.

5.2. Multi-Stakeholder Administration is Hard

Delegating the administration of a necessarily centralized function
(see Section 3.2) 4.2) to a multi-stakeholder body is an onerous but
sometimes necessary way occasionally used to
mitigate the undesirable its effects.

A multi-stakeholder body is an institution that includes
representatives of the different kinds of parties that are affected
by the system's operation ('stakeholders') ("stakeholders") in an attempt to make
well-reasoned, broadly agreed-to, and authoritative decisions.

The most relevant example of this technique is the administration of
the Domain Name System [RFC1035], which as a 'single "single source of truth'
requires truth"
exhibits necessary centralization of the naming function. function, as well as
the operation of the system. To mitigate operational centralization,
this task is carried out by multiple root servers that are
administered by separate operators -- themselves diverse in geography
and a selection of corporate entities, non-profits and government
bodies from many jurisdictions and affiliations. Furthermore, those operators are the
name space itself is regulated by ICANN
(https://www.icann.org/resources/pages/governance/governance-en),
which is defined as a globally multi-stakeholder body with
representation from a end users, governments, operators, and others.

Another example of multi-stakeholderism is the standardization of
Internet protocols themselves. Because a specification effectively
controls the behavior of implementations that are conformant with it,
the standardization process can be seen as a single point of control.
As a result, Internet standards bodies like the IETF allow open
participation and contribution, make decisions in an open and
accountable way, have a well-defined process for making (and when
necessary, appealing) decisions, and take taking into account the views of
different stakeholder groups [RFC8890].

Yet another example is the administration of the Web's trust model,
implemented by Web browsers as relying parties and Certificate
Authorities as trust anchors. To assure that all parties meet the
operational and security requirements necessary to provide the
desired properties, the CA/Browser Forum (https://cabforum.org) was
established as an oversight body that involves both of those parties
as stakeholders.

In each of these examples, setup and ongoing operation of a multi-
stakeholder organization is not trivial. This is the a major downside of such an
this approach. Additionally, the legitimacy of such an organization
cannot be assumed, and may be difficult to establish and maintain
(see, eg, [LEGITIMACY-MULTI]). This concern is especially relevant
if the function being coordinated is broad, complex, and/or
contentious.

4.3.

5.3. Blockchains Are Not Magical

Increasingly, distributed consensus technologies such as the
blockchain are touted as a solution to centralization issues. A
complete survey of this rapidly-changing area is beyond the scope of
this document, but at a high level, we can generalise about their
properties.

These techniques attempt to avoid centralization risk by distributing
intermediary or otherwise potentially centralized functions to
members of a large pool of protocol participants. Verification of
proper performance of a function is typically guaranteed using
cryptographic techniques (often, an append-only transaction ledger).
The assignment of a particular task to a node for handling usually
cannot be predicted or controlled. To assure diversity

Sybil attacks (where enough participants coordinate their activity to
affect the protocol's operation) are a major concern for these
protocols. Diversity in the pool of participants (thereby preventing Sybil attacks), is encouraged using
indirect techniques such as proof-of-work (where each participant has
to demonstrate significant consumption of resources) or proof-of-stake proof-of-
stake (where each participant has some other incentive to execute correctly) are used.

As such,
correctly).

Appropriate use of these techniques purposefully disallow can create barriers to direct centralization and are robust against
inherited centralization. Depending However, depending upon the application in
question, indirect and platform centralization may can still be possible, but in general these techniques do not lend
themselves to these ends as readily as federated systems do.

However, possible.

Furthermore, distributed consensus technologies have several
potential shortcomings that may make them inappropriate -- or at
least difficult to use -- for many Internet applications, because
their use conflicts with other important goals:

1. Distributed consensus protocols can have significant implications
for privacy. Because activity (such as queries or transactions)
are shared with many unknown parties, they have very different
privacy properties than traditional client/server protocols.
Mitigations (e.g., Private Information Retrieval; see, eg, [PIR])
are still not suitable for broad deployment.

2. Their complexity and 'chattiness' "chattiness" typically results result in
significantly less efficient use of the network. network (often, to
several orders of magnitude). When distributed consensus
protocols use proof-of-work, energy consumption can become
significant (to the point where some jurisdictions have banned
its use).

3. Distributed consensus protocols are still not proven to scale to
the degree expected of successful Internet protocols. In
particular, relying on unknown third parties to deliver
functionality can introduce variability in latency, availability,
and throughput. This is a marked change for applications with
high expectations for these properties (e.g., commercial Web
services).

4. By design, distributed consensus protocols diffuse responsibility
for a function among several, difficult-to-identify parties.
While this may be an effective way to prevent many some kinds of
centralization, it also means that making someone accountable for
how the function is performed is impossible, beyond the bounds of
the protocol's design.

It is also important to recognise that a protocol or an application
can use distributed consensus for some functions, but still have
centralization risk elsewhere. Even when distributed consensus is
used exclusively (which is uncommon, due to the associated costs),
some degree of coordination is still necessary -- whether that be
through governance of the function itself, creation of shared
implementations, or documentation of shared wire protocols. That
represents centralization risk, just at a different layer (inherited
or platform, depending on the circumstances).

These potential shortcomings do not rule out the use of distributed
consensus technologies for every use case. They do, however, caution
against relying upon these technologies to avoid centralization
uncritically.

5. Guidelines

6. What Should Internet Standards Do?

Centralization is driven by powerful forces -- both economic and
social -- as well as the network effects that come with Internet
scale. Moreover, because permissionless innovation is a core value
for Protocol Designers

While the following recommendations Internet, and yet much of the centralization seen on the
Internet is performed by proprietary platforms that take advantage of
this nature, the controls available to standards efforts on their own
are not a complete guide, they very limited.

Nevertheless, while standards bodies on their own cannot prevent
centralization, there are meaningful steps that can be taken to
prevent some functions from exhibiting some forms of centralization.
There are also valuable contributions that standards efforts can make
to other relevant forms of regulation.

6.1. Manage Centralization Risk Where Effective

Some types of centralization risk are relatively easy to manage in
standards efforts. A directly centralized protocol, were it to be
proposed, would be rejected out of hand by the IETF. There is a starting point
growning body of knowledge and experience with necessary
centralization, and a strong inclination to reuse existing
infrastructure where possible. As discussed above, encryption is
often a way to manage inherited centralization. All of these
responses are appropriate ways for avoiding or mitigating Internet standards to manage
centralization risk.

However, precluding indirect and platform centralization are much
more difficult in standards efforts. Because we have no "protocol
police", it's not possible to demand that someone stop building a
proprietary service using a purportedly federated protocol. We also
cannot stop someone from building centralized services "on top" of
standard protocols without violating architectural goals like
permissionless innovation.

Therefore, committing significant resources to scrutinizing protocols
for hidden or latent centralization risk -- especially for indirect
and platform risks -- is unlikely to actually prevent Internet
centralization. Almost all existing Internet protocols -- including
IP, TCP, HTTP, and DNS -- suffer some form of indirect or platform
centralization. Refusing to standardize a newer protocol because it
faces similar risks would not be equitable, proportionate, or
effective.

Centralization risk is sometimes perceived to be in tension with
other goals, such as privacy. While there is rarely a pure tradeoff
between two abstract goals such as these, when it does occur
attention should be paid to how effective architectural regulation
(such as a standards effort) is in achieving each goal. In this
example, a technical mechanism might be much more effective at
improving privacy, whereas centralization might be better controlled
by other regulators -- leading to the conclusion that the standards
effort should focus on privacy.

6.2. Create Standards to Decentralize Proprietary Functions

Standards efforts should focus on creating new specifications for
functions that are currently only satisfied by proprietary,
centralized protocols.

5.1. Allow Intermediation Sparingly For example, if social networking is thought
to be a centralized function, this might mean creating specifications
that enable decentralized social networking, perhaps using some or
all of the techniques described in Section 5.

Keen readers will point out that social networking is effectively
centralized despite the existence of such standards (see, e.g.,
[W3C.CR-activitystreams-core-20161215]), because the IETF and W3C
create voluntary standards, not mandatory regulations.

However, architecture is not the only form of regulation; legal
mechanisms combined with changing norms and the resulting market
forces have their own regulatory effects [NEW-CHICAGO]. While for
much of its lifetime the Internet has only been subject to limited
legal regulation, that period appears to be ending.

It is far from certain that a legal mandate for interoperability
based upon Internet standards will eventuate, but it is increasingly
discussed as a remedy for competition issues (see, e.g., [OECD]). It
is also not certain that legally-mandated standards will fully
address centralization risks. However, if such specifications are
not available from the Internet community, they may be created
elsewhere without reference to the Internet's architectural goals.

Even absent a legal mandate, changes in norms and the market -- due
to increasing knowledge and distrust of centralized functions -- can
create demand for such specifications and the corresponding
implementations.

6.3. Limit Intermediary Power

The introduction of an intermediary role -- i.e., one that performs a
function but is not a first party to communication -- adds indirect
and platform centralization risk to Internet protocols, because it
brings opportunities for control and observation. Even when At the protocol is
federated (see Section 4.1) to avoid direct centralization,
significant indirect centralization risks exist when intermediation
is allowed.

However, same time,
intermediation can sometimes add often adds significant value to a protocol, or enable enables
what is considered a necessary function. In such
cases, the centralized function SHOULD be as minimal as possible, and
expose only the information and pontential for control necessary for
that function

While (as discussed above) standards efforts have a very limited
capability to be performed. Protocol designers SHOULD consider
the likely deployment patterns for those intermediaries prevent or control indirect and how
network effects platform
centralization, constraints on intermediary functions -- when
designed explicitly into a protocol -- and other factors will influence them.

Such predictions prevent at least the most
egregious outcomes. In general, this can be difficult. For example, an intermediary
interposed achieved by limiting the end user
nature of a protocol might allow them the intermediary role to delegate
functions the most minimal function
possible.

For example, HTTP allows intermediaries to a party see the full content of
traffic by default, even when they trust, thereby empowering them. are only performing basic
functions such as routing. However,
if an intervening network is able to force users with the introduction of HTTPS
and the CONNECT method (see Section 9.3.6 of [HTTP]), combined with
market forces to delegate adopt HTTPS, those intermediaries now only have
access to a
particular intermediary, inherited centralization could result. the appropriate routing information.

When carefully considered, intermediation can be a powerful way to
enforce functional boundaries -- for example, to reduce the need for
users to trust potentially malicious endpoints, as seen in the so-
called 'oblivious' protocols currently in development (e.g.,
[I-D.pauly-dprive-oblivious-doh]) that allow end users to hide their
identity from services, while still accessing them.

The same advice applies in these cases; the observation and control
potential SHOULD be as minimal as possible, while still meeting the
design goals of the protocol.

See [I-D.thomson-tmi] for more guidance.

5.2. Encrypt, Always

When deployed at scale, encryption can be an effective technique to
reduce many inherited centralization risks. By reducing the number
of parties who have access to content of communication, the ability

Another kind of lower-layer protocols and intermediaries at those layers to
interfere with or observe intermediation is precluded. Even when they can still
prevent communication, the use of encryption makes it more difficult
to discriminate the target from other traffic.

Note that the benefits are most pronounced created when the majority (if not
all) traffic is encrypted. As a result, protocols SHOULD be
encrypted by default.