idnits 2.17.1 draft-thomson-postel-was-wrong-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 760 (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational October 27, 2017 5 Expires: April 30, 2018 7 The Harmful Consequences of the Robustness Principle 8 draft-thomson-postel-was-wrong-02 10 Abstract 12 Jon Postel's famous statement in RFC 1122 of "Be liberal in what you 13 accept, and conservative in what you send" is a principle that has 14 long guided the design and implementation of Internet protocols. The 15 posture this statement advocates promotes interoperability, but can 16 produce negative effects in the protocol ecosystem in the long term. 17 Those effects can be avoided by properly maintaining protocols. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 30, 2018. 36 Copyright Notice 38 Copyright (c) 2017 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3 55 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5 57 5. An Alternative Conclusion . . . . . . . . . . . . . . . . . . 6 58 6. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 7 59 6.1. Fault Reporting is Valuable . . . . . . . . . . . . . . . 7 60 6.2. The Role of Strict Error Handling . . . . . . . . . . . . 7 61 7. Implementations Are Ultimately Responsible . . . . . . . . . 8 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 10. Informative References . . . . . . . . . . . . . . . . . . . 9 65 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 10 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 68 1. Introduction 70 Of the great many contributions Jon Postel made to the Internet, his 71 remarkable technical achievements are often ignored in favor of the 72 design and implementation philosophy of what is known as the 73 robustness principle: 75 Be strict when sending and tolerant when receiving. 76 Implementations must follow specifications precisely when sending 77 to the network, and tolerate faulty input from the network. When 78 in doubt, discard faulty input silently, without returning an 79 error message unless this is required by the specification. 81 This being the version of the text that appears in IAB RFC 1958 82 [PRINCIPLES]. 84 In comparison, his contributions to the underpinnings of the 85 Internet, which are in many respects more significant, enjoy less 86 conscious recognition. Postel's robustness principle has been hugely 87 influential in shaping the Internet and the systems that use Internet 88 protocols. Many consider this principle to be instrumental in the 89 success of the Internet as well as the design of interoperable 90 protocols in general. 92 Over time, considerable changes have occurred in both the scale of 93 the Internet and the level of skill and experience available to 94 protocol and software designers. Much of that experience is with 95 protocols that were designed, informed by Postel's maxim, in the 96 early phases of the Internet. 98 That experience shows that there are negative long-term consequences 99 to interoperability if an implementation applies Postel's advice. 100 Correcting the problems caused by divergent behavior in 101 implementations can be difficult. 103 This document describes the negative consequences of the application 104 of Postel's principle to the modern Internet. It recommends against 105 following Postel's advice, instead recommending that protocols 106 receive continuing maintenance after their initial design and 107 deployment. Active maintenance of protocols reduces or eliminates 108 the opportunities to apply Postel's guidance. 110 There is good evidence to suggest that protocols are routinely 111 maintained beyond their inception. This document serves primarily as 112 a record of the shortcomings of the robustness principle. 114 2. Fallibility of Specifications 116 What is often missed in discussions of the robustness principle is 117 the context in which it appears. The earliest form of the principle 118 in the RFC series (in RFC 760 [RFC0760]) is preceded by a sentence 119 that reveals the motivation for the principle: 121 While the goal of this specification is to be explicit about the 122 protocol there is the possibility of differing interpretations. 123 In general, an implementation should be conservative in its 124 sending behavior, and liberal in its receiving behavior. 126 This motivating statement is a frank admission of fallibility and 127 remarkable for it. Here Postel recognizes the possibility that the 128 specification could be imperfect. This is an important statement, 129 but inexplicably absent from the later versions in [HOSTS] and 130 [PRINCIPLES]. 132 Indeed, an imperfect specification is natural, largely because it was 133 - and remains thus - more important to proceed to implementation and 134 deployment than it is to perfect the protocol specification. A 135 protocol, like software, benefits greatly from experience in 136 deployment, and a deployed protocol is immeasurably more useful than 137 a perfect protocol. 139 As shown [SUCCESS] demonstrates, success or failure of a protocol 140 depends far more on factors like usefulness than on on technical 141 excellence. Postel's timely publication of protocol specifications, 142 even with the potential for flaws, likely had a significant effect in 143 the eventual success of the Internet. 145 The problem is therefore not with the premise, but with its 146 conclusion: the robustness principle itself. 148 3. Protocol Decay 150 Divergent implementations of a specification emerge over time. When 151 variations occur in the interpretation or expression of semantic 152 components, implementations cease to be perfectly interoperable. 154 Implementation bugs are often identified as the cause of variation, 155 though it is often a combination of factors. Application of a 156 protocol to new and unanticipated uses, and ambiguities or errors in 157 the specification are often confounding factors. Situations where 158 two peers disagree on interpretation should be expected over the 159 lifetime of a protocol. 161 Even with the best intentions, the pressure to interoperate can be 162 significant. No implementation can hope to avoid having to trade 163 correctness for interoperability indefinitely. 165 An implementation that reacts to variations in the manner advised by 166 Postel sets up a feedback cycle: 168 o Over time, implementations progressively add new code to constrain 169 how data is transmitted, or to permit variations in what is 170 received. 172 o Errors in implementations, or confusion about semantics can 173 thereby be masked. 175 o These errors can become entrenched, forcing other implementations 176 to be tolerant of those errors. 178 In this way an flaw can become entrenched as a de facto standard. 179 Any implementation of the protocol is required to replicate the 180 aberrant behavior, or it is not interoperable. This is both a 181 consequence of applying Postel's advice, and a product of a natural 182 reluctance to avoid fatal error conditions. Ensuring 183 interoperability in this environment is often colloquially referred 184 to as aiming to be "bug for bug compatible". 186 For example, in TLS [RFC5246] messages use an extension format with a 187 tag-length-value format. TLS extensions can be added to handshake 188 messages in any order. However, some server implementations 189 terminate connections if they encounter a TLS ClientHello message 190 that ends with an empty extension. Thus, client implementations are 191 required to be aware of this incompatibility and ensure that a 192 ClientHello message ends in a non-empty extension. 194 While TLS highlights the potential for implementation error to cause 195 problems, the original JSON specification [RFC4627] demonstrates the 196 effect of specification shortcomings. RFC 4627 omitted critical 197 details on a range of key details including Unicode handling, 198 ordering and duplication of object members, and number encoding. 199 Consequently, a range of interpretations were used by 200 implementations. An updated JSON specification [RFC7159] was unable 201 to correct these errors, instead concentrating on defining the 202 interoperable subset of JSON. I-JSON [RFC7493] defines a new format 203 that is substantially similar to JSON while prohibiting the 204 problematic variations. However, that prohibition means that I-JSON 205 is not fully interoperable: an I-JSON implementation will fail to 206 accept some valid JSON texts. Consequently, I-JSON is not widely 207 implemented in parsers. Many JSON parsers instead implement the more 208 precise algorithm specified in [ECMA262]. 210 It is debatable as to whether decay can be completely avoided, but 211 the robustness principle encourages a reaction that compounds 212 problems. 214 4. Ecosystem Effects 216 Once deviations become entrenched, it can be extremely difficult - if 217 not impossible - to rectify the situation. 219 For widely used protocols, the massive scale of the Internet makes 220 large-scale interoperability testing infeasible for all but a 221 privileged few. As the set of changes needed to maintain 222 interoperability grows in size, the cost of building a new 223 implementation increases. This is particularly relevant as the set 224 of tweaks necessary for interoperability can be difficult to learn. 226 Consequently, new implementations can be restricted to niche uses, 227 where the problems arising from interoperability issues can be more 228 closely managed. Restricting new implementations to narrow contexts 229 also risks causing forks in the protocol. If implementations cannot 230 interoperate, the chances of the addition of further incompatible 231 changes is significant. 233 This has a negative impact on the ecosystem of a protocol. New 234 implementations are important in ensuring the continued viability of 235 a protocol. New protocol implementations are also more likely to be 236 developed for new and diverse use cases and often are the origin of 237 features and capabilities that can be of benefit to existing users. 239 The need to work around interoperability problems also reduce the 240 ability of established implementations to change. For instance, an 241 accumulation of mitigations for interoperability issues makes 242 implementations more difficult to maintain. 244 5. An Alternative Conclusion 246 The robustness principle is best suited to safeguarding against flaws 247 in a specification that is intended to remain unchanged for an 248 extended period of time. Indeed, in the face of divergent 249 interpretations of an immutable specification, the only hope for an 250 implementation to remain interoperable is to be tolerant of 251 differences in interpretation and occasional outright implementation 252 errors. 254 From this perspective, application of Postel's advice to the 255 implementation of a protocol specification that does not change is 256 logical, even necessary. But that suggests that the problem is with 257 the presumption of immutability of specifications. 259 Active maintenance of a protocol can ensure that specifications 260 remain accurate and that new implementations are possible. A 261 maintained protocol is not a static construct, it improves and 262 changes as it is used. 264 Protocol designers are strongly encouraged to continue to maintain 265 and evolve protocols beyond their initial inception and definition. 266 Maintenance is needed in response to the discovery of errors in 267 specification that might cause interoperability issues. Maintenance 268 is also critical for ensuring that the protocol is viable for 269 application to use cases that might not have been envisaged during 270 its original design. New use cases are an indicator that the 271 protocol could be successful [SUCCESS]. 273 Maintenance does not demand the development of new versions of 274 protocols or protocol specifications. For instance, RFC 793 [TCP] 275 remains the canonical TCP reference, but that document alone is no 276 longer sufficient to implement the protocol. TCP is the subject of a 277 very large number of update and extension RFCs that together document 278 the deployed protocol. 280 Good extensibility [EXT] can make it easier to respond to new use 281 cases or changes in the environment in which the protocol is 282 deployed. 284 The process of maintenance ideally begins even before the 285 specification for a protocol is complete. Neglect can quickly 286 produce the negative consequences this document describes. Restoring 287 the protocol to a state where it can be maintained involves first 288 discovering the properties of the protocol as it is deployed, rather 289 than the protocol as it was originally documented. This can be 290 difficult and time-consuming, particularly if the protocol has a 291 diverse set of implementations. Such a process was undertaken for 292 HTTP [HTTP] after a period of minimal maintenance. Restoring the 293 specification to currency took significant effort over more than 6 294 years. 296 6. The Role of Feedback 298 Protocol maintenance is only possible if there is sufficient 299 information about the deployment of the protocol. Feedback from 300 deployment is critical to effective protocol maintenance. 302 For a protocol specification, the primary and most effective form of 303 feedback comes from people who implement or deploy the protocol. An 304 active community of protocol implementers and users is the most 305 valuable source of feedback. It is this community that implements 306 and deploys changes, in addition to contributing to the ongoing 307 maintenance of protocol specifications. 309 6.1. Fault Reporting is Valuable 311 Protocol implementations should include automated error reporting 312 mechanisms. 314 Exposing faults through operations and management systems is highly 315 valuable, but it might be necessary to ensure that the information is 316 propagated further. 318 Building telemetry and error logging systems that report faults to 319 the developers of the implementation is superior in many respects. 320 However, this is only possible in deployments that are conducive to 321 the collection of this type of information. Giving consideration to 322 protection of the privacy of protocol participants is critical prior 323 to deploying any such system. 325 6.2. The Role of Strict Error Handling 327 Favoring strict error handling over attempting error recovery is an 328 effective technique for ensuring that faults receive attention. 330 A fatal errors provide excellent motivation to address problems. 331 However, generating fatal errors is only feasible if such errors are 332 sufficiently rare. Frequent problems can result in users to ignoring 333 them or finding workarounds, whereas rare events demand greater 334 attention. 336 Fatal errors or crashes are also preferable if there is any risk that 337 the error might represent an implementation or security issue. 339 Exposing errors is particularly important for early implementations 340 of a protocol. Enabling stricter error handling helps validate the 341 design of both protocol and implementations. If strict checks are 342 retained when implementations are more widely deployed, those checks 343 better enable the detection and correction of errors in new 344 implementations. 346 This doesn't mean that protocol implementations need to treat all 347 inputs equally strictly. A protocol could be designed with the 348 explicit goal of accepting a wide range of inputs (see for example 349 [HTML]). As long as proper reactions to inputs are clearly and 350 unambiguously specified, these considerations don't apply. 352 7. Implementations Are Ultimately Responsible 354 Implementations and deployments are critical to the ongoing 355 maintenance of a protocol. Implementations have ample motivation to 356 prefer stability and interoperability over maintenance or 357 correctness. It is likely that - over time - an implementation will 358 accumulate allowances for errors of specification or implementation. 359 Without care, this can lead to suppression of feedback about 360 problems. 362 Even when an implementation chooses to attempt to adapt to an 363 abnormal condition, communicating that decision to the community is 364 valuable. At a minimum, it allows others to benefit from knowledge 365 of the problem. Discussion about problems might also lead to 366 alternative strategies or protocol enhancements that can avoid 367 further problems. 369 Over time, mitigations for interoperability issues could become 370 redundant. Occasional review of any special interoperability 371 measures might reveal opportunities for an implementation to switch 372 to stricter handling of exceptional conditions. Removing special 373 allowances in favor of stricter error reporting restores feedback 374 measures that new implementations can then benefit from. 376 Managing and deploying changes can be expensive. However, it is 377 widely recognized that maintenance is a critical part of the 378 deployment of computer systems for security reasons [IOTSU]. 379 Managing updates for interoperability problems represents a small 380 additional cost in exchange for ensuring the ability to interoperate 381 with other users of the network. 383 8. Security Considerations 385 Sloppy implementations, lax interpretations of specifications, and 386 uncoordinated extrapolation of requirements to cover gaps in 387 specification can result in security problems. Hiding the 388 consequences of protocol variations encourages the hiding of issues, 389 which can conceal bugs and make them difficult to discover. 391 Designers and implementers of security protocols generally understand 392 these concerns. However, general-purpose protocols are not exempt 393 from careful consideration of security issues. Furthermore, because 394 general-purpose protocols tend to deal with flaws or obsolescence in 395 a less urgent fashion than security protocols, there can be fewer 396 opportunities to correct problems in protocols that develop 397 interoperability problems. 399 9. IANA Considerations 401 This document has no IANA actions. 403 10. Informative References 405 [ECMA262] "ECMAScript(R) 2017 Language Specification", ECMA-262 8th 406 Edition, June 2017, . 409 [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 410 Considerations for Protocol Extensions", RFC 6709, 411 DOI 10.17487/RFC6709, September 2012, 412 . 414 [HOSTS] Braden, R., Ed., "Requirements for Internet Hosts - 415 Communication Layers", STD 3, RFC 1122, 416 DOI 10.17487/RFC1122, October 1989, 417 . 419 [HTML] "HTML", WHATWG Living Standard, October 2017, 420 . 422 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 423 Protocol (HTTP/1.1): Message Syntax and Routing", 424 RFC 7230, DOI 10.17487/RFC7230, June 2014, 425 . 427 [IOTSU] Tschofenig, H. and S. Farrell, "Report from the Internet 428 of Things Software Update (IoTSU) Workshop 2016", 429 RFC 8240, DOI 10.17487/RFC8240, September 2017, 430 . 432 [PRINCIPLES] 433 Carpenter, B., Ed., "Architectural Principles of the 434 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 435 . 437 [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, 438 DOI 10.17487/RFC0760, January 1980, 439 . 441 [RFC4627] Crockford, D., "The application/json Media Type for 442 JavaScript Object Notation (JSON)", RFC 4627, 443 DOI 10.17487/RFC4627, July 2006, 444 . 446 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 447 (TLS) Protocol Version 1.2", RFC 5246, 448 DOI 10.17487/RFC5246, August 2008, 449 . 451 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 452 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 453 2014, . 455 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 456 DOI 10.17487/RFC7493, March 2015, 457 . 459 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 460 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 461 . 463 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 464 RFC 793, DOI 10.17487/RFC0793, September 1981, 465 . 467 Appendix A. Acknowledgments 469 Constructive feedback on this document has been provided by a 470 surprising number of people including Mark Nottingham, Brian 471 Trammell, and Anne Van Kesteren. Please excuse any omission. 473 Author's Address 475 Martin Thomson 476 Mozilla 478 Email: martin.thomson@gmail.com