draft-iab-protocol-maintenance-01.txt   draft-iab-protocol-maintenance-02.txt 
Network Working Group M. Thomson Network Working Group M. Thomson
Internet-Draft Mozilla Internet-Draft Mozilla
Intended status: Informational October 22, 2018 Intended status: Informational March 11, 2019
Expires: April 25, 2019 Expires: September 12, 2019
The Harmful Consequences of the Robustness Principle The Harmful Consequences of the Robustness Principle
draft-iab-protocol-maintenance-01 draft-iab-protocol-maintenance-02
Abstract Abstract
Jon Postel's famous statement of "Be liberal in what you accept, and Jon Postel's famous statement of "Be liberal in what you accept, and
conservative in what you send" is a principle that has long guided conservative in what you send" is a principle that has long guided
the design and implementation of Internet protocols. The posture the design and implementation of Internet protocols. The posture
this statement advocates promotes interoperability in the short term, this statement advocates promotes interoperability in the short term,
but can negatively affect the protocol ecosystem. For a protocol but can negatively affect the protocol ecosystem. For a protocol
that is actively maintained, the Postel's robustness principle can, that is actively maintained, the Postel's robustness principle can,
and should, be avoided. and should, be avoided.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 5 skipping to change at page 5, line 5
to be tolerant of those errors. to be tolerant of those errors.
A flaw can become entrenched as a de facto standard. Any A flaw can become entrenched as a de facto standard. Any
implementation of the protocol is required to replicate the aberrant implementation of the protocol is required to replicate the aberrant
behavior, or it is not interoperable. This is both a consequence of behavior, or it is not interoperable. This is both a consequence of
applying Postel's advice, and a product of a natural reluctance to applying Postel's advice, and a product of a natural reluctance to
avoid fatal error conditions. Ensuring interoperability in this avoid fatal error conditions. Ensuring interoperability in this
environment is often colloquially referred to as aiming to be "bug environment is often colloquially referred to as aiming to be "bug
for bug compatible". for bug compatible".
For example, TLS demonstrates the effect of bugs. In TLS [TLS] For example, in TLS [TLS] extensions use a tag-length-value format,
extensions use a tag-length-value format, and they can be added to and they can be added to messages in any order. However, some server
messages in any order. However, some server implementations implementations terminate connections if they encounter a TLS
terminate connections if they encounter a TLS ClientHello message ClientHello message that ends with an empty extension. To maintain
that ends with an empty extension. To maintain interoperability, interoperability, client implementations are required to be aware of
client implementations are required to be aware of this bug and this bug and ensure that a ClientHello message ends in a non-empty
ensure that a ClientHello message ends in a non-empty extension. extension.
The original JSON specification [JSON] demonstrates the effect of The original JSON specification [JSON] demonstrates the effect of
specification shortcomings. RFC 4627 omitted critical details on a specification shortcomings. RFC 4627 omitted critical details on a
range of key details including Unicode handling, ordering and range of key details including Unicode handling, ordering and
duplication of object members, and number encoding. Consequently, a duplication of object members, and number encoding. Consequently, a
range of interpretations were used by implementations. An updated range of interpretations were used by implementations. An updated
specification [JSON-BIS] did not correct these errors, concentrating specification [JSON-BIS] did not correct these errors, concentrating
instead on identifying the interoperable subset of JSON. I-JSON instead on identifying the interoperable subset of JSON. I-JSON
[I-JSON] takes that subset and defines a new format that prohibits [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 the problematic parts of JSON. Of course, that means that I-JSON is
skipping to change at page 5, line 38 skipping to change at page 5, line 38
4. Ecosystem Effects 4. Ecosystem Effects
Once deviations become entrenched, it can be extremely difficult - if Once deviations become entrenched, it can be extremely difficult - if
not impossible - to rectify the situation. not impossible - to rectify the situation.
For widely used protocols, the massive scale of the Internet makes For widely used protocols, the massive scale of the Internet makes
large-scale interoperability testing infeasible for all but a large-scale interoperability testing infeasible for all but a
privileged few. The cost of building a new implementation increases privileged few. The cost of building a new implementation increases
as the number of implementations and bugs increases. Worse, the set as the number of implementations and bugs increases. Worse, the set
of tweaks necessary for interoperability can be difficult to learn. of tweaks necessary for wide interoperability can be difficult to
discover.
Consequently, new implementations can be restricted to niche uses, Consequently, new implementations can be restricted to niche uses,
where the problems arising from interoperability issues can be more where the problems arising from interoperability issues can be more
closely managed. Restricting new implementations to narrow contexts closely managed. Restricting new implementations to narrow contexts
also risks causing forks in the protocol. If implementations do not also risks causing forks in the protocol. If implementations do not
interoperate, little prevents those implementations from diverging interoperate, little prevents those implementations from diverging
more over time. more over time.
This has a negative impact on the ecosystem of a protocol. New This has a negative impact on the ecosystem of a protocol. New
implementations are important in ensuring the continued viability of implementations are important in ensuring the continued viability of
skipping to change at page 6, line 39 skipping to change at page 6, line 39
specification, the best way for an implementation to remain specification, the best way for an implementation to remain
interoperable is to be tolerant of differences in interpretation and interoperable is to be tolerant of differences in interpretation and
an occasional outright implementation error. an occasional outright implementation error.
From this perspective, application of Postel's advice to the From this perspective, application of Postel's advice to the
implementation of a protocol specification that does not change is implementation of a protocol specification that does not change is
logical, even necessary. But that suggests that the problem is with logical, even necessary. But that suggests that the problem is with
the assumption that the situation - existing specifications and the assumption that the situation - existing specifications and
implementations - are unable to change. implementations - are unable to change.
As already established, this is not a sustainable. For a protocol to As already established, this is not sustainable. For a protocol to
be viable, it is necessary for both specifications and be viable, it is necessary for both specifications and
implementations to be responsive to changes, in addition to handling implementations to be responsive to changes, in addition to handling
new and old problems that might arise over time. new and old problems that might arise over time.
Active maintenance of a protocol is critical in ensuring that Active maintenance of a protocol is critical in ensuring that
specifications correctly reflect the requirements for specifications correctly reflect the requirements for
interoperability with existing implementations. Maintenance enables interoperability. Maintenance enables both new implementations and
both new implementations and the continued improvement of the the continued improvement of the protocol. New use cases are an
protocol. New use cases are an indicator that the protocol could be indicator that the protocol could be successful [SUCCESS].
successful [SUCCESS].
Protocol designers are strongly encouraged to continue to maintain Protocol designers are strongly encouraged to continue to maintain
and evolve protocols beyond their initial inception and definition. and evolve protocols beyond their initial inception and definition.
Involvement of protocol implementers is a critical part of this Involvement of protocol implementers is a critical part of this
process, as they provide input on their experience with process, as they provide input on their experience with
implementation and deployment of the protocol. implementation and deployment of the protocol.
Maintenance does not necessarily involve the development of new Most interoperability problems do not require revision of protocols
versions of protocols or protocol specifications. For instance, the or protocol specifications. For instance, the most effective means
most effective means of dealing with a defective implementation in a of dealing with a defective implementation in a peer could be to
peer is often to email the developer of the stack. It is far more email the developer of the stack. It is far more efficient in the
efficient in the long term to fix one isolated bug than it is to deal long term to fix one isolated bug than it is to deal with the
with the consequences of workarounds. consequences of workarounds.
Neglect can quickly produce the negative consequences this document Neglect can quickly produce the negative consequences this document
describes. Restoring the protocol to a state where it can be describes. Restoring the protocol to a state where it can be
maintained involves first discovering the properties of the protocol maintained involves first discovering the properties of the protocol
as it is deployed, rather than the protocol as it was originally as it is deployed, rather than the protocol as it was originally
documented. This can be difficult and time-consuming, particularly documented. This can be difficult and time-consuming, particularly
if the protocol has a diverse set of implementations. Such a process if the protocol has a diverse set of implementations. Such a process
was undertaken for HTTP [HTTP] after a period of minimal maintenance. was undertaken for HTTP [HTTP] after a period of minimal maintenance.
Restoring HTTP specifications to currency took significant effort. Restoring HTTP specifications to currency took significant effort.
skipping to change at page 8, line 46 skipping to change at page 8, line 44
7.2. Virtuous Intolerance 7.2. Virtuous Intolerance
A well-specified protocol includes rules for consistent handling of A well-specified protocol includes rules for consistent handling of
aberrant conditions. This increases the changes that implementations aberrant conditions. This increases the changes that implementations
have interoperable handling of unusual conditions. have interoperable handling of unusual conditions.
Intolerance of any deviation from specification, where Intolerance of any deviation from specification, where
implementations generate fatal errors in response to observing implementations generate fatal errors in response to observing
undefined or unusal behaviour, can be harnessed to reduce occurrences undefined or unusal behaviour, can be harnessed to reduce occurrences
of abherrent implementations. Choosing to generate fatal error for of aberrant implementations. Choosing to generate fatal errors for
unspecified conditions instead of attempting error recovery can unspecified conditions instead of attempting error recovery can
ensure that faults receive attention. ensure that faults receive attention.
This improves feedback for new implementations in particular. When a This improves feedback for new implementations in particular. When a
new implementation encounters a virtuously intolerant implementation, new implementation encounters a virtuously intolerant implementation,
it receives strong feedback that allows problems to be discovered it receives strong feedback that allows problems to be discovered
quickly. quickly.
To be effective, virtuously intolerant implementations need to be To be effective, virtuously intolerant implementations need to be
sufficiently widely deployed that they are encountered by new sufficiently widely deployed that they are encountered by new
implementations with high probability. This could depend on multiple implementations with high probability. This could depend on multiple
implementations of the same strict checks. Any intolerance also implementations of strict checks. Any intolerance also needs to be
needs to be strongly supported by specifications, otherwise they strongly supported by specifications, otherwise they encourage
encourage fracturing of the protocol community or proliferation of fracturing of the protocol community or proliferation of workarounds.
workarounds.
Virtuous intolerance can be used to motivate compliance with any Virtuous intolerance can be used to motivate compliance with any
protocol requirement. For instance, the INADEQUATE_SECURITY error protocol requirement. For instance, the INADEQUATE_SECURITY error
code and associated requirements in HTTP/2 [HTTP2] resulted in code and associated requirements in HTTP/2 [HTTP2] resulted in
improvements in the security of the deployed base. improvements in the security of the deployed base.
8. Security Considerations 8. Security Considerations
Sloppy implementations, lax interpretations of specifications, and Sloppy implementations, lax interpretations of specifications, and
uncoordinated extrapolation of requirements to cover gaps in uncoordinated extrapolation of requirements to cover gaps in
skipping to change at page 9, line 38 skipping to change at page 9, line 35
The consequences of the problems described in this document are The consequences of the problems described in this document are
especially acute for any protocol where security depends on agreement especially acute for any protocol where security depends on agreement
about semantics of protocol elements. about semantics of protocol elements.
9. IANA Considerations 9. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
10. Informative References 10. Informative References
[ECMA262] "ECMAScript(R) 2017 Language Specification", ECMA-262 8th [ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th
Edition, June 2017, <http://www.ecma- Edition, June 2018, <https://www.ecma-
international.org/publications/standards/Ecma-262.htm>. international.org/publications/standards/Ecma-262.htm>.
[EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709, Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012, DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>. <https://www.rfc-editor.org/info/rfc6709>.
[HOSTS] Braden, R., Ed., "Requirements for Internet Hosts - [HOSTS] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[HTML] "HTML", WHATWG Living Standard, October 2017, [HTML] "HTML", WHATWG Living Standard, March 2019,
<https://html.spec.whatwg.org/>. <https://html.spec.whatwg.org/>.
[HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
skipping to change at page 11, line 28 skipping to change at page 11, line 23
Constructive feedback on this document has been provided by a Constructive feedback on this document has been provided by a
surprising number of people including Bernard Aboba, Brian Carpenter, surprising number of people including Bernard Aboba, Brian Carpenter,
Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks, Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks,
Brian Trammell, and Anne Van Kesteren. Please excuse any omission. Brian Trammell, and Anne Van Kesteren. Please excuse any omission.
Author's Address Author's Address
Martin Thomson Martin Thomson
Mozilla Mozilla
Email: martin.thomson@gmail.com Email: mt@lowentropy.net
 End of changes. 15 change blocks. 
33 lines changed or deleted 31 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/