The Harmful Consequences of the Robustness Principle
Mozilla
mt@lowentropy.net
The robustness principle, often phrased as “be conservative in what you send,
and liberal in what you accept”, has long guided the design and implementation
of Internet protocols. The posture this statement advocates promotes
interoperability in the short term, but can negatively affect the protocol
ecosystem over time. For a protocol that is actively maintained, the robustness
principle can, and should, be avoided.
Discussion of this document takes place on the
Architecture-Discuss mailing list (architecture-discuss@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/architecture-discuss/.
Source for this draft and an issue tracker can be found at
https://github.com/intarchboard/protocol-maintenance.
The robustness principle has been hugely influential in shaping the design of
the Internet. As stated in IAB RFC 1958 , the robustness
principle advises to:
Be strict when sending and tolerant when receiving. Implementations must
follow specifications precisely when sending to the network, and tolerate
faulty input from the network. When in doubt, discard faulty input silently,
without returning an error message unless this is required by the
specification.
This simple statement captures a significant concept in the design of
interoperable systems. Many consider the application of the robustness
principle to be instrumental in the success of the Internet as well as the
design of interoperable protocols in general.
Time and experience shows that negative consequences to interoperability
accumulate over time if implementations apply the robustness principle. This
problem originates from an assumption implicit in the principle that it is not
possible to affect change in a system the size of the Internet. That is, the
idea that once a protocol specification is published, changes that might require
existing implementations to change are not feasible.
Many problems that might lead to applications of the robustness principle are
avoided for protocols under active maintenance. Active protocol maintenance is
where a community of protocol designers, implementers, and deployers work
together to continuously improve and evolve protocol specifications alongside
implementations and deployments of those protocols. A community that takes an
active role in the maintenance of protocols can greatly reduce and even
eliminate opportunities to apply the robustness principle.
There is good evidence to suggest that many important protocols are routinely
maintained beyond their inception. In particular, a sizeable proportion of IETF
activity is dedicated to the stewardship of existing protocols. This document
serves primarily as a record of the hazards inherent in applying the robustness
principle and to offer an alternative strategy for handling interoperability
problems in deployments.
Ideally, protocol implementations never have to apply the robustness principle.
Or, where it is unavoidable, use of the robustness principle is viewed as a
short term workaround that needs to be quickly reverted.
The context from which the robustness principle was developed provides valuable
insights into its intent and purpose. The earliest form of the principle in the
RFC series (in RFC 760 ) is preceded by a sentence that reveals
the motivation for the principle:
While the goal of this specification is to be explicit about the protocol
there is the possibility of differing interpretations. In general, an
implementation should be conservative in its sending behavior, and liberal in
its receiving behavior.
This formulation of the principle expressly recognizes the possibility that the
specification could be imperfect. This contextualizes the principle in an
important way.
An imperfect specification is natural, largely because it is more important to
proceed to implementation and deployment than it is to perfect a specification.
A protocol, like any complex system, benefits greatly from experience with its
use. A deployed protocol is immeasurably more useful than a perfect protocol.
The robustness principle is a tool that is suited to early phases of system
design.
As demonstrates, success or failure of a protocol depends
far more on factors like usefulness than on on technical excellence. Timely
publication of protocol specifications, even with the potential for flaws,
likely contributed significantly to the eventual success of the Internet.
The problem is therefore not with the premise, but with its conclusion: the
robustness principle itself.
The application of the robustness principle to the early Internet, or any system
that is in early phases of deployment, is expedient. The consequence of
applying the principle is deferring the effort of dealing with interoperability
problems, which can amplify the ultimate cost of handling those problems.
Divergent implementations of a specification emerge over time. When variations
occur in the interpretation or expression of semantic components,
implementations cease to be perfectly interoperable.
Implementation bugs are often identified as the cause of variation, though it is
often a combination of factors. Application of a protocol to uses that were not
anticipated in the original design, or ambiguities and errors in the
specification are often confounding factors. Disagreements on the
interpretation of specifications should be expected over the lifetime of a
protocol.
Even with the best intentions, the pressure to interoperate can be significant.
No implementation can hope to avoid having to trade correctness for
interoperability indefinitely.
An implementation that reacts to variations in the manner recommended in the
robustness principle sets up a feedback cycle. Over time:
Implementations progressively add logic to constrain how data is transmitted,
or to permit variations in what is received.
Errors in implementations or confusion about semantics are permitted or
ignored.
These errors can become entrenched, forcing other implementations to be
tolerant of those errors.
A flaw can become entrenched as a de facto standard. Any implementation of the
protocol is required to replicate the aberrant behavior, or it is not
interoperable. This is both a consequence of applying the robustness principle,
and a product of a natural reluctance to avoid fatal error conditions. Ensuring
interoperability in this environment is often referred to as aiming to be “bug
for bug compatible”.
For example, in TLS extensions use a tag-length-value format,
and they can be added to messages in any order. However, some server
implementations terminate connections if they encounter a TLS ClientHello
message that ends with an empty extension. To maintain interoperability, client
implementations are required to be aware of this bug and ensure that a
ClientHello message ends in a non-empty extension.
The original JSON specification demonstrates the effect of
specification shortcomings. RFC 4627 omitted critical details on a range of key
details including Unicode handling, ordering and duplication of object members,
and number encoding. Consequently, a range of interpretations were used by
implementations. An updated specification did not correct
these errors, concentrating instead on identifying the interoperable subset of
JSON. I-JSON takes that subset and defines a new format
that prohibits the problematic parts of JSON. Of course, that means that I-JSON
is not fully interoperable with JSON. Consequently, I-JSON is not widely
implemented in parsers. Many JSON parsers now implement the more precise
algorithm specified in .
The robustness principle therefore encourages a reaction that can create
interoperability problems. In particular, the application of the robustness
principle is particularly deleterious for early implementations of new protocols
as quirks in early implementations can affect all subsequent deployments.
Once deviations become entrenched, it can be extremely difficult - if not
impossible - to rectify the situation.
Interoperability requirements for protocol implementations are set by other
deployments. Specifications and - where they exist - conformance test suites
might guide the initial development of implementations, but implementations
ultimately need to interoperate with deployed implementations.
For widely used protocols, the massive scale of the Internet makes large-scale
interoperability testing infeasible for all but a privileged few. The cost of
building a new implementation using reverse engineering increases as the number
of implementations and bugs increases. Worse, the set of tweaks necessary for
wide interoperability can be difficult to discover.
Consequently, new implementations might be forced into niche uses, where the
problems arising from interoperability issues can be more closely managed.
However, restricting new implementations into limited deployments risks causing
forks in the protocol. If implementations do not interoperate, little prevents
those implementations from diverging more over time.
This has a negative impact on the ecosystem of a protocol. New implementations
are important in ensuring the continued viability of a protocol. New protocol
implementations are also more likely to be developed for new and diverse use
cases and often are the origin of features and capabilities that can be of
benefit to existing users.
The need to work around interoperability problems also reduces the ability of
established implementations to change. An accumulation of mitigations for
interoperability issues makes implementations more difficult to maintain and can
constrain extensibility (see also ).
Sometimes what appear to be interoperability problems are symptomatic of issues
in protocol design. A community that is willing to make changes to the
protocol, by revising or extending it, makes the protocol better in the process.
Applying the robustness principle instead conceals problems, making it harder,
or even impossible, to fix them later.
The robustness principle can be highly effective in safeguarding against flaws
in the implementation of a protocol by peers. Especially when a specification
remains unchanged for an extended period of time, the inclination to be tolerant
accumulates over time. Indeed, when faced with divergent interpretations of an
immutable specification, the best way for an implementation to remain
interoperable is to be tolerant of differences in interpretation and
implementation errors.
From this perspective, application of the robustness principle to the
implementation of a protocol specification that does not change is logical, even
necessary. But that suggests that the problem is with the assumption that
existing specifications and implementations are unable to change. Applying the
robustness principle in this way disproportionately values short-term gains over
the negative effects on future implementations and the protocol as a whole.
For a protocol to have sustained viability, it is necessary for both
specifications and implementations to be responsive to changes, in addition to
handling new and old problems that might arise over time.
Maintaining specifications so that they closely match deployments ensures that
implementations are consistently interoperable and removes needless barriers for
new implementations. Maintenance also enables continued improvement of the
protocol. New use cases are an indicator that the protocol could be successful
.
Protocol designers are strongly encouraged to continue to maintain and evolve
protocol specificationss beyond their initial inception and definition. This
might require the development of revised specifications, extensions, or other
supporting material that documents the current state of the protocol.
Involvement of those who implement and deploy the protocol is a critical part of
this process, as they provide input on their experience with how the protocol is
used.
Most interoperability problems do not require revision of protocols or protocol
specifications. For instance, the most effective means of dealing with a
defective implementation in a peer could be to email the developer responsible.
It is far more efficient in the long term to fix one isolated bug than it is to
deal with the consequences of workarounds.
Early implementations of protocols have a stronger obligation to closely follow
specifications as their behavior will affect all subsequent implementations.
Protocol specifications might need more frequent revision during early
deployments to capture feedback from early rounds of deployment.
Neglect can quickly produce the negative consequences this document describes.
Restoring the protocol to a state where it can be maintained involves first
discovering the properties of the protocol as it is deployed, rather than the
protocol as it was originally documented. This can be difficult and
time-consuming, particularly if the protocol has a diverse set of
implementations. Such a process was undertaken for HTTP after
a period of minimal maintenance. Restoring HTTP specifications to currency took
significant effort.
Maintenance is most effective if it is responsive, which is greatly affected by
how rapidly protocol changes can be deployed. For protocol deployments that
operate on longer time scales, temporary workarounds following the spirit of the
robustness principle might be necessary. If specifications can be updated more
readily than deployments, details of the workaround can be document, including
the desired form of the protocols once the need for workarounds no longer exists
and plans for removing the workaround.
Good extensibility can make it easier to respond to new use
cases or changes in the environment in which the protocol is deployed.
Extensibility is sometimes mistaken for an application of the robustness
principle. After all, if one party wants to start using a new feature before
another party is prepared to receive it, it might be assumed that the receiving
party is being tolerant of unexpected inputs.
A well-designed extensibility mechanism establishes clear rules for the handling
of things like new messages or parameters. If an extension mechanism is
designed and implemented correctly, new protocol features can be deployed with
confidence in the understanding of the effect they have on existing
implementations.
In contrast, relying on implementations to consistently apply the robustness
principle is not a good strategy for extensibility. Using undocumented or
accidental features of a protocol as the basis of an extensibility mechanism can
be extremely difficult, as is demonstrated by the case study in Appendix A.3 of
.
A protocol could be designed to permit a narrow set of valid inputs, or it could
allow a wide range of inputs as a core feature (see for example ).
Specifying and implementing a more flexible protocol is more difficult; allowing
less variability is preferable in the absence of strong reasons to be flexible.
A well-specified protocol includes rules for consistent handling of aberrant
conditions. This increases the chances that implementations will have
interoperable handling of unusual conditions.
Intolerance of any deviation from specification, where implementations generate
fatal errors in response to observing undefined or unusual behaviour, can be
harnessed to reduce occurrences of aberrant implementations. Choosing to
generate fatal errors for unspecified conditions instead of attempting error
recovery can ensure that faults receive attention.
This improves feedback for new implementations in particular. When a new
implementation encounters an intolerant implementation, it receives strong
feedback that allows problems to be discovered quickly.
To be effective, intolerant implementations need to be sufficiently widely
deployed that they are encountered by new implementations with high probability.
This could depend on multiple implementations deploying strict checks.
Any intolerance also needs to be strongly supported by specifications, otherwise
they encourage fracturing of the protocol community or proliferation of
workarounds (see ).
Intolerance can be used to motivate compliance with any protocol requirement.
For instance, the INADEQUATE_SECURITY error code and associated requirements in
HTTP/2 resulted in improvements in the security of the
deployed base.
Any protocol participant that is affected by changes arising from maintenance
might be excluded if they are unwilling or unable to implement or deploy changes
that are made to the protocol.
Deliberate exclusion of problematic implementations is an important tool that
can ensure that the interoperability of a protocol remains viable. While
compatible changes are always preferable to incompatible ones, it is not always
possible to produce a design that protects the ability of all current and future
protocol participants to interoperate. Developing and deploying changes that
risk exclusion of previously interoperating implementations requires some care,
but changes to a protocol should not be blocked on the grounds of the risk of
exclusion alone.
Exclusion is a direct goal when choosing to be intolerant of errors (see
), which is deployed with the intent of protecting future
interoperability.
Excluding implementations or deployments can lead to a fracturing of the
protocol system that could be more harmful than any divergence resulting from
following the robustness principle. RFC 5704
describes how conflict or competition in the maintenance of protocols can lead
to similar problems.
Sloppy implementations, lax interpretations of specifications, and uncoordinated
extrapolation of requirements to cover gaps in specification can result in
security problems. Hiding the consequences of protocol variations encourages
the hiding of issues, which can conceal bugs and make them difficult to
discover.
The consequences of the problems described in this document are especially acute
for any protocol where security depends on agreement about semantics of protocol
elements. For instance, use of unsafe security mechanisms, such as weak
primitives or obsolete mechanisms , are good
examples of where forcing exclusion () can be desirable.
This document has no IANA actions.
ECMAScript(R) 2018 Language Specification
HTML
Architectural Principles of the Internet
The Internet and its architecture have grown in evolutionary fashion from modest beginnings, rather than from a Grand Plan. While this process of evolution is one of the main reasons for the technology's success, it nevertheless seems useful to record a snapshot of the current principles of the Internet architecture. This is intended for general guidance and general interest, and is in no way intended to be a formal or invariant reference model. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.
DoD standard Internet Protocol
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.
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.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.
The application/json Media Type for JavaScript Object Notation (JSON)
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This memo provides information for the Internet community.
The JavaScript Object Notation (JSON) Data Interchange Format
JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data.This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.
The I-JSON Message Format
I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.
Long-term Viability of Protocol Extension Mechanisms
The ability to change protocols depends on exercising the extension and version negotiation mechanisms that support change. Protocols that don't use these mechanisms can find that deploying changes can be difficult and costly.
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.
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.
Hypertext Transfer Protocol Version 2 (HTTP/2)
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Uncoordinated Protocol Development Considered Harmful
IAB
This document identifies problems that may result from the absence of formal coordination and joint development on protocols of mutual interest between standards development organizations (SDOs). Some of these problems may cause significant harm to the Internet. The document suggests that a robust procedure is required prevent this from occurring in the future. The IAB has selected a number of case studies, such as Transport MPLS (T-MPLS), as recent examples to describe the hazard to the Internet architecture that results from uncoordinated adaptation of a protocol.This experience has resulted in a considerable improvement in the relationship between the IETF and the ITU-T. In particular, this was achieved via the establishment of the "Joint working team on MPLS-TP". In addition, the leadership of the two organizations agreed to improve inter-organizational working practices so as to avoid conflict in the future between ITU-T Recommendations and IETF RFCs.Whilst we use ITU-T - IETF interactions in these case studies, the scope of the document extends to all SDOs that have an overlapping protocol interest with the IETF. This memo provides information for the Internet community.
Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms
This document updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes.
Deprecating Secure Sockets Layer Version 3.0
The Secure Sockets Layer version 3.0 (SSLv3), as specified in RFC 6101, is not sufficiently secure. This document requires that SSLv3 not be used. The replacement versions, in particular, Transport Layer Security (TLS) 1.2 (RFC 5246), are considerably more secure and capable protocols.This document updates the backward compatibility section of RFC 5246 and its predecessors to prohibit fallback to SSLv3.
Constructive feedback on this document has been provided by a surprising number
of people including Bernard Aboba, Brian Carpenter, Stuart Cheshire, Mark
Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks, Brian Trammell,
and Anne Van Kesteren. Please excuse any omission.