RFC 8890 - The Internet is for End Users
Mark Nottingham
recent entries<br>all entries<br>feed
Hi, I’m Mark Nottingham.<br>I write about the Web, protocol design, HTTP, Internet governance, and more. This is a personal<br>blog, it does not represent anyone else.<br>Find out more.
Comments? Let's talk on Mastodon.<br>@mnot@techpolicy.social
other Standards posts
The Nature of Internet Standards (series)
RFC 9518 - What Can Internet Standards Do About Centralisation?<br>Tuesday, 19 December 2023
How to Read an RFC<br>Tuesday, 31 July 2018
RFC 8890 - The Internet is for End Users
Friday, 28 August 2020
Standards
The Internet Architecture Board (IAB) has published RFC8890, The Internet is for End Users, arguing that the Internet Engineering Task Force (IETF) should ground its decisions in what’s good for people who use the Internet, and that it should take positive steps to achieve that.
Why does this need to be said? Is it going too far? Who else could they favour, and why should you care? As author of the RFC and a member of the IAB that passed it, here are my thoughts.
How the Internet is made
The IETF plays a central role in the design and operation of the Internet. Formed in the 1980s by the engineers who created several of the Internet’s core technologies, it is the primary venue for documenting the technical design of the Internet, and has overseen development of protocols like TCP, IP, DNS and HTTP.
Companies, governments and other organisations don’t officially participate in the IETF; people only represent themselves. There isn’t even a concept of membership. Instead, decisions about specifications are made by ‘rough consensus’ — instead of formal voting, the IETF tries to find the best solution for each issue, based upon the ideas, comments and concerns brought to it.
‘Best' doesn't mean the choice that has the most companies supporting it; it’s the one that has the best technical arguments behind it. Working Group chairs measure that consensus; if someone thinks they got it wrong, they can appeal it through a chain of authorities selected for their experience.
Or, in the words of the unofficial IETF credo: ‘We reject kings, presidents and voting. We believe in rough consensus and running code.’
Technical or political? Both
Naturally, most IETF decisions are about technical details; what bytes should go where, how a server reacts to a client, and so on. Because of this, participants often tell themselves that their decisions aren't ever political; that any such concerns are on ‘layer 8’ — referring to the stack of seven abstractions commonly used for network protocols — and therefore nothing to be concerned about.
“[T]he running code that results from our process (when things work well) inevitably has an impact beyond technical considerations, because the underlying decisions afford some uses while discouraging others.”
— The Internet is for End Users
However, the barrier between the bits on the wire and political matters has turned out to be leaky, like most abstractions are. Sometimes the ability to send information (or the prevention of it) has real-world consequences that take power from some people and give it to others. Likewise with the ability to see what other people are saying, and to control the format in which they speak.
So, in a world that is increasingly intertwined with the Internet, it’s becoming more difficult to maintain the position that the design of Internet protocols doesn't have a political dimension. All decisions have the possibility of bias; of advantaging or disadvantaging different parties.
For example, the recent standardisation of DNS-over-HTTPS (DoH) pitted advocates for dissidents and protestors against network operators who use DNS for centralised network management, and child safety advocates who promote DNS-based filtering solutions. If the IETF were to only decide upon technical merit, how would it balance these interests?
Another example is the Encrypted Client Hello proposal, which closes a loophole that shares the identity of HTTPS sites you visit with anyone listening. China has reportedly started blocking connections that use it, so in a purely technical sense, it will not work well because some networks block it. Should the IETF stop working on it?
Yet another example: how should the IETF handle a proposal to allow networks to decrypt or intermediate HTTPS connections? Is that OK if it’s merely technically sound? What if the user agrees to it, and what does ‘consent’ mean? Many such proposals have been made, but not approved. Why?
If the IETF’s decisions affect the design of the Internet, and the Internet is political, the IETF’s decisions are sometimes political too. However, its decision-making processes presume that there is a technically correct answer to each problem. When that decision affects people and power in the actual world, rough consensus and running code are insufficient.
Over the years, these questions have become increasingly urgent,...