Factors Influencing the Freedom to Change Protocols
Mozilla
martin.thomson@gmail.com
The ability to change protocols depends on exercising that ability. Protocols
that don’t change can find that the mechanisms that support change become
unusable.
A successful protocol will change in ways that allow it to continue
to fulfill the needs of its users. New use cases, conditions and constraints on
the deployment of a protocol can render a protocol that does not change
obsolete.
Usage patterns and requirements for a protocol shift over time. Protocols can
react to these shifts in one of three ways: adjust usage patterns within the
constraints of the protocol, extend the protocol, and replace the protocol.
These reactions are progressively more disruptive, but are also dictated by the
nature of the change in requirements over longer periods.
Experience with Internet scale protocol deployment shows that changing protocols
is not uniformly successful. examines the
problem more broadly.
This document examines the specific conditions that determine whether protocol
maintainers have the ability - the freedom - to design and deploy new or
modified protocols.
A change to a protocol can be made extremely difficult to deploy if there are
bugs in implementations with which the new deployment needs to interoperate.
Bugs in the handling of new codepoints or extensions can mean that instead of
handling the mechanism as designed, endpoints react poorly. This can manifest
as abrupt termination of sessions, errors, crashes, or disappearances of
endpoints and timeouts.
Interoperability with other implementations is usually highly valued, so
deploying mechanisms that trigger adverse reactions like these can be untenable.
Where interoperability is a competitive advantage, this is true even if the
negative reactions happen infrequently or only under relatively rare conditions.
Deploying a change to a protocol could require fixing a substantial proportion
of the bugs that the change exposes. This can involve a difficult process that
includes identifying the cause of these errors, finding the responsible
implementation, coordinating a bug fix and release plan, contacting the operator
of affected services, and waiting for the fix to be deployed to those services.
Given the effort involved in fixing these problems, the existence of these sorts
of bugs can outright prevent the deployment of some types of protocol changes.
It could even be necessary to come up with a new protocol design that uses a
different method to achieve the same result.
It is often argued that the design of a protocol extension point or version
negotiation capability is critical to the freedom that it ultimately offers.
RFC 6709 contains a great deal of well-considered advice on
designing for extension. It includes the following advice:
This means that, to be useful, a protocol version- negotiation mechanism
should be simple enough that it can reasonably be assumed that all the
implementers of the first protocol version at least managed to implement the
version-negotiation mechanism correctly.
This has proven to be insufficient in practice. Many protocols have evidence of
imperfect implementation of these critical mechanisms. Mechanisms that aren’t
used are the ones that fail most often. The same paragraph from RFC 6709
acknowledges the existence of this problem, but does not offer any remedy:
The nature of protocol version-negotiation mechanisms is that, by definition,
they don’t get widespread real-world testing until after the base protocol
has been deployed for a while, and its deficiencies have become evident.
Transport Layer Security (TLS) provides examples of where a design
that is objectively sound fails when incorrectly implemented. TLS provides
examples of failures in protocol version negotiation and extensibility.
Version negotiation in TLS 1.2 and earlier uses the “Highest mutually supported
version (HMSV)” exactly as described in . However, clients are
unable to advertise a new version without causing a non-trivial proportions of
sessions to fail due to bugs in server (or middlebox) implementations.
It is possible that some middleboxes prevent negotiation of protocol versions
and features they do not understand. It is hard to imagine what those
middleboxes hope to gain from doing so for a protocol like TLS.
Intolerance to new TLS versions is so severe that TLS 1.3
has abandoned HMSV version negotiation for a different
mechanism.
The server name indication (SNI) in TLS is another excellent
example of the failure of a well-designed extensibility point. SNI uses the
same technique for extension that is used with considerable success in other
parts of the TLS protocol. The original design of SNI includes the ability to
include multiple names of different types.
What is telling in this case is that SNI was defined with just one type of name:
a domain name. No other type has ever been defined, though several have been
proposed. Despite an otherwise exemplary design, SNI is so inconsistently
implemented that any hope for using the extension point it defines has been
abandoned .
Even the most superficially simple protocols can often involve more actors than
is immediately apparent. A two-party protocol still has two ends, and even at
the endpoints of an interaction, protocol elements can be passed on to other
entities in ways that can affect protcol operation.
One of the key challenges in deploying new features in a protocol is ensuring
compatibility with all actors that could influence the outcome.
Protocols that deploy without active measures against intermediation can accrue
middleboxes that depend on certain aspects of the protocol. In particular, one
of the consequences of an unencrypted protocol is that any element on path can
interact with the protocol. For example, HTTP recognizes the role of a
transparent proxy . Because HTTP was specifically designed with
intermediation in mind, transparent proxies are not only possible, but sometimes
advantageous. Consequently, transparent proxies for HTTP are commonplace.
Middleboxes are also protocol participants, to the degree that they are able to
observe and act in ways that affect the protocol. The degree to which a
middlebox participates varies from the basic functions that a router performs to
full participation. For example, a SIP back-to-back user agent (B2BUA)
can be very deeply involved in the SIP protocol.
By increasing the number of different actors involved in any single protocol
exchange, the number of potential implementation bugs that a deployment needs to
contend with also increases. In particular, incompatible changes to a protocol
that might be negotiated between endpoints in ignorance of the presence of a
middlebox can result in a middlebox acting badly.
Thus, middleboxes can increase the difficulty of deploying changes to a protocol
considerably.
If design is insufficient, what then would give protocol designers the freedom
to later change a deployed protocol?
Michel Foucault defines freedom as a practice rather than a state that is
bestowed or attained:
Freedom is practice; […] the freedom of men is never assured by the laws
and the institutions that are intended to guarantee them. […] I think it
can never be inherent in the structure of things to guarantee the exercise of
freedom. The guarantee of freedom is freedom. –
In the same way, the design of a protocol for extensibility and eventual
replacement does not guarantee the ability to exercise those
options.
Though planning and specifying these options is a necessarily precondition for
their availability, whether they are available depends on more than what is
written in a specification. The nature a protocol deployment has a significant
effect on whether that protocol can be changed.
This is why I emphasize practices of freedom over processes of liberation;
again, the latter indeed have their place, but they do not seem to me, to be
capable by themselves of defining all the practical forms of freedom.
–
The fact that freedom depends on practice is evident in protocols that are known
to have viable version negotiation or extension points. The definition of
mechanisms alone is insufficient, it’s the active use of those mechanisms that
determines the existence of freedom.
For example, header fields in email , HTTP and SIP
all derive from the same basic design. There is no evidence of any
barriers to deploying header fields with new names and semantics.
In another example, the attribute-value pairs (AVPs) in Diameter
are fundamental to the design of the protocol. The definition of new uses of
Diameter regularly exercise the ability to add new AVPs and do so with no fear
that the definition might be unsuccessful.
These examples show extension points that are heavily used also being relatively
unaffected by deployment issues. These examples also confirm the case that good
design is not a prerequisite for success. On the contrary, success is often
despite shortcomings in the design. For instance, the shortcomings of HTTP
header fields are significant enough that there are ongoing efforts to improve
the syntax .
Only using a protocol capability is able to ensure availability of that
capability. Protocols that fail to use a mechanism, or a protocol that only
rarely uses a mechanism, suffer an inability to rely on that mechanism.
The best way to guarantee that a protocol mechanism is used is to make it
critical to an endpoint participating in that protocol. This means that
implementations rely on both the existence of a mechanism and it being used.
For example, the message format in SMTP relies on header fields for most of its
functions, including the most basic functions. A deployment of SMTP cannot
avoid including an implementation of header field handling. In addition to
this, the regularity with which new header fields are defined and used ensures
that deployments frequently encounter header fields that it does not understand.
An SMTP implementation therefore needs to be able to both process header fields
that it understands and ignore those that it does not.
In this way, implementing the extensibility mechanism is not merely mandated by
the specification, it is critical to the functioning of a protocol deployment.
Should an implementation fail to correctly implement the mechanism, that failure
would become immediately apparent.
In contrast, there are many examples of extension points in protocols that have
been either completely unused, or their use was so infrequent that they could no
longer be relied upon to function correctly.
HTTP has a number of very effective extension points in addition to the
aforementioned header fields. It also has some examples of extension point that
are so rarely used that it is possible that they are not at all usable.
Extension points in HTTP that might be unwise to use include the extension point
on each chunk in the chunked transfer coding , the ability to use
transfer codings other than the chunked coding, and the range unit in a range
request .
There are several potential approaches that can provide some measure of
protection against a protocol deployment becoming resistant to change.
“Grease” identifies lack of use as an issue (protocol
mechanisms “rusting” shut) and proposes a system of use that exercises extension
points by using dummy values.
The grease design aims at the style of negotiation most used in TLS, where the
client offers a set of options and the server chooses the one that it most
prefers from those that it supports. In that design, the client randomly offers
options (usually just one) from a set of reserved values. These values are
guaranteed to never be assigned real meaning, so the server will never have
cause to genuinely select one of these values.
The principle that grease operates on is that an implementation that is
regularly exposed to unknown values is not likely to become intolerant of new
values when they appear. This depends somewhat on the fact that the difficulty
of implementing the protocol mechanism correctly is not significantly more
effort than implementing code to specifically filter out the randomized “grease”
values. To that end, the values that are reserved are not taken from a single
contiguous block of code points, but are distributed across the entire space of
code points.
The hope with grease is that errors in implementing the mechanisms it safeguards
are quickly detected. If many implementations send these “grease” values as
part of regular operation, then any failure to properly handle these apparently
new values will be detected.
This form of defensive design has some limitations. It does not necessarily
create the need for an implementation to rely on the mechanism it safeguards;
that is determined by the underlying protocol itself. More critically, it does
not easily translate to other forms of extension point. Other techniques might
be necessary for protocols that don’t rely on the particular style of exchange
that is predominant in TLS.
A method of defensive design is that of using cryptography (such as TLS) to
forcibly reduce the number of entities that can participate in the protocol.
Data that is exchanged under encryption cannot be seen by middleboxes, excluding
them from participating in that part of the protocol. Similarly, data that is
exchanged with integrity protection cannot be modified by middleboxes.
The QUIC protocol , adopts both encryption to
carefully control what information is exposed to middleboxes. QUIC also uses
integrity protection over all the data it exchanges to prevent modification.
Modern software engineering practice includes a strong emphasis on measuring the
effects of changes and correcting based on that feedback. Runtime monitoring of
system health is an important part of that, which relies on systems of logging
and synthetic health indicators, such as aggregate transaction failure rates.
Feedback is critical to the success of the grease technique (see ).
The system only works if an implementer creates a way to ensure that errors are
detected and analyzed. This process can be automated, but when operating at
scale it might be difficult or impossible to collect details of specific errors.
Treating errors in protocol implementation as fatal can greatly improve
visibility. Disabling automatic recovery from protocol errors can be disruptive
to users when those errors occur, but it also ensures that errors are made
visible. Where users are part of the feedback system, visibility of error
conditions is especially important.
New protocol designs are encouraged to define conditions that result in fatal
errors. Competitive pressures often force implementations to favor strategies
that mask or hide errors. Standardizing on error handling that ensures
visibility of flaws avoids handling that hides problems.
Feedback on errors can be more important during the development and early
deployment of a change. Disabling automatic error recovery methods during
development can improve visibility of errors.
Automated feedback systems are important for automated systems, or where error
recovery is also automated. For instance, failures to connect to HTTP
alternative services are not permitted to affect the outcome of
transactions. A feedback system for capturing failures in alternative services
is therefore crucial to ensuring the mechanism remains viable.
The ability to design, implement, and deploy new protocol mechanisms can be
critical to security. In particular, the need to be able to replace
cryptographic algorithms over time has been well established .
This document makes no request of IANA.
The Foucault Reader
Ethics: Subjectivity and Truth
Accepting that other SNI name types will never work
Re: [TLS] Thoughts on Version Intolerance
What Makes For a Successful Protocol?
The Internet community has specified a large number of protocols to date, and these protocols have achieved varying degrees of success. Based on case studies, this document attempts to ascertain factors that contribute to or hinder a protocol's success. It is hoped that these observations can serve as guidance for future protocol work. This memo provides information for the Internet community.
Planning for Protocol Adoption and Subsequent Transitions
Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions, and thus some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and also summarizes what makes for a good transition plan.
Design Considerations for Protocol Extensions
This document discusses architectural issues related to the extensibility of Internet protocols, with a focus on design considerations. It is intended to assist designers of both base protocols and extensions. Case studies are included. A companion document, RFC 4775 (BCP 125), discusses procedures relating to the extensibility of IETF protocols. This document is not an Internet Standards Track specification; it is published for informational purposes.
The Transport Layer Security (TLS) Protocol Version 1.2
This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK]
The Transport Layer Security (TLS) Protocol Version 1.3
This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.
Transport Layer Security (TLS) Extensions: Extension Definitions
This document provides specifications for existing TLS extensions. It is a companion document for RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2". The extensions specified are server_name, max_fragment_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_request. [STANDARDS-TRACK]
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.
A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.
Internet Message Format
This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]
SIP: Session Initiation Protocol
This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]
Diameter Base Protocol
The Diameter base protocol is intended to provide an Authentication, Authorization, and Accounting (AAA) framework for applications such as network access or IP mobility in both local and roaming situations. This document specifies the message format, transport, error reporting, accounting, and security services used by all Diameter applications. The Diameter base protocol as defined in this document obsoletes RFC 3588 and RFC 5719, and it must be supported by all new Diameter implementations. [STANDARDS-TRACK]
HTTP Header Common Structure
An abstract data model for HTTP headers, "Common Structure", and a HTTP/1 serialization of it, generalized from current HTTP headers. Note to Readers Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/ . Working Group information can be found at http://httpwg.github.io/ ; source code and issues list for this draft can be found at https://github.com/httpwg/http-extensions/labels/header-structure .
Hypertext Transfer Protocol (HTTP/1.1): Range Requests
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.
Applying GREASE to TLS Extensibility
This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised by clients to ensure servers correctly handle unknown values.
QUIC: A UDP-Based Multiplexed and Secure Transport
QUIC is a multiplexed and secure transport protocol that runs on top of UDP. QUIC builds on past transport experience, and implements mechanisms that make it useful as a modern general-purpose transport protocol. Using UDP as the basis of QUIC is intended to address compatibility issues with legacy clients and middleboxes. QUIC authenticates all of its headers, preventing third parties from changing them. QUIC encrypts most of its headers, thereby limiting protocol evolution to QUIC endpoints only. Therefore, middleboxes, in large part, are not required to be updated as new protocol versions are deployed. This document describes the core QUIC protocol, including the conceptual design, wire format, and mechanisms of the QUIC protocol for connection establishment, stream multiplexing, stream and connection-level flow control, and data reliability. Accompanying documents describe QUIC's loss recovery and congestion control, and the use of TLS 1.3 for key negotiation.
HTTP Alternative Services
This document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.
Guidelines for Cryptographic Algorithm Agility and Selecting Mandatory-to-Implement Algorithms
Many IETF protocols use cryptographic algorithms to provide confidentiality, integrity, authentication, or digital signature. Communicating peers must support a common set of cryptographic algorithms for these mechanisms to work properly. This memo provides guidelines to ensure that protocols have the ability to migrate from one mandatory-to-implement algorithm suite to another over time.