idnits 2.17.1 draft-iab-protocol-maintenance-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 (March 11, 2019) is 1866 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 7540 (ref. 'HTTP2') (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 760 (ref. 'IP') (Obsoleted by RFC 791) -- Obsolete informational reference (is this intentional?): RFC 4627 (ref. 'JSON') (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 7159 (ref. 'JSON-BIS') (Obsoleted by RFC 8259) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) 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 March 11, 2019 5 Expires: September 12, 2019 7 The Harmful Consequences of the Robustness Principle 8 draft-iab-protocol-maintenance-02 10 Abstract 12 Jon Postel's famous statement of "Be liberal in what you accept, and 13 conservative in what you send" is a principle that has long guided 14 the design and implementation of Internet protocols. The posture 15 this statement advocates promotes interoperability in the short term, 16 but can negatively affect the protocol ecosystem. For a protocol 17 that is actively maintained, the Postel's robustness principle can, 18 and should, be avoided. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3 56 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6 59 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. The Role of Feedback . . . . . . . . . . . . . . . . . . . . 8 61 7.1. Feedback from Implementations . . . . . . . . . . . . . . 8 62 7.2. Virtuous Intolerance . . . . . . . . . . . . . . . . . . 8 63 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 10. Informative References . . . . . . . . . . . . . . . . . . . 9 66 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 11 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 Of the great many contributions Jon Postel made to the Internet, his 72 remarkable technical achievements are often shadowed by his 73 contribution of a design and implementation philosophy known as the 74 robustness principle: 76 Be strict when sending and tolerant when receiving. 77 Implementations must follow specifications precisely when sending 78 to the network, and tolerate faulty input from the network. When 79 in doubt, discard faulty input silently, without returning an 80 error message unless this is required by the specification. 82 This being the version of the text that appears in IAB RFC 1958 83 [PRINCIPLES]. 85 Postel's robustness principle has been hugely influential in shaping 86 the Internet and the systems that use Internet protocols. Many 87 consider the application of the robustness principle to be 88 instrumental in the success of the Internet as well as the design of 89 interoperable protocols in general. 91 Over time, considerable experience has been accumulated with 92 protocols that were designed by the application of Postel's maxim. 93 That experience shows that there are negative long-term consequences 94 to interoperability if an implementation applies Postel's advice. 96 The flaw in Postel's logic originates from the presumption of an 97 inability to affect change in a system the size of the Internet. 98 That is, once a protocol specification is published, changes that 99 might be different to the practice of existing implementations are 100 not feasible. 102 Many of the shortcomings that lead to applications of the robustness 103 principle are avoided for protocols under active maintenance. Active 104 protocol maintenance is where a community of protocol designers, 105 implementers, and deployers continuously improve and evolve 106 protocols. A community that takes an active role in the maintenance 107 of protocols can greatly reduce and even eliminate opportunities to 108 apply Postel's guidance. 110 There is good evidence to suggest that many important protocols are 111 routinely maintained beyond their inception. This document serves 112 primarily as a record of the hazards inherent in applying the 113 robustness principle and to offer an alternative strategy for 114 handling interoperability problems in deployments. 116 Ideally, protocol implementations never have to apply the robustness 117 principle. Or, where it is unavoidable, any application can be 118 quickly reverted. 120 2. Fallibility of Specifications 122 The context from which the robustness principle was developed 123 provides valuable insights into its intent and purpose. The earliest 124 form of the principle in the RFC series (in RFC 760 [IP]) is preceded 125 by a sentence that reveals the motivation for the principle: 127 While the goal of this specification is to be explicit about the 128 protocol there is the possibility of differing interpretations. 129 In general, an implementation should be conservative in its 130 sending behavior, and liberal in its receiving behavior. 132 Here Postel recognizes the possibility that the specification could 133 be imperfect. As a frank admission of fallibility it is a 134 significant statement. However, the same statement is inexplicably 135 absent from the later versions in [HOSTS] and [PRINCIPLES]. 137 An imperfect specification is natural, largely because it is more 138 important to proceed to implementation and deployment than it is to 139 perfect a specification. A protocol, like any complex system, 140 benefits greatly from experience with its use. A deployed protocol 141 is immeasurably more useful than a perfect protocol. 143 As [SUCCESS] demonstrates, success or failure of a protocol depends 144 far more on factors like usefulness than on on technical excellence. 145 Postel's timely publication of protocol specifications, even with the 146 potential for flaws, likely had a significant effect in the eventual 147 success of the Internet. 149 The problem is therefore not with the premise, but with its 150 conclusion: the robustness principle itself. 152 3. Protocol Decay 154 Divergent implementations of a specification emerge over time. When 155 variations occur in the interpretation or expression of semantic 156 components, implementations cease to be perfectly interoperable. 158 Implementation bugs are often identified as the cause of variation, 159 though it is often a combination of factors. Application of a 160 protocol to new and unanticipated uses, and ambiguities or errors in 161 the specification are often confounding factors. Situations where 162 two peers disagree on interpretation should be expected over the 163 lifetime of a protocol. 165 Even with the best intentions, the pressure to interoperate can be 166 significant. No implementation can hope to avoid having to trade 167 correctness for interoperability indefinitely. 169 An implementation that reacts to variations in the manner advised by 170 Postel sets up a feedback cycle: 172 o Over time, implementations progressively add new code to constrain 173 how data is transmitted, or to permit variations in what is 174 received. 176 o Errors in implementations, or confusion about semantics can 177 thereby be masked. 179 o These errors can become entrenched, forcing other implementations 180 to be tolerant of those errors. 182 A flaw can become entrenched as a de facto standard. Any 183 implementation of the protocol is required to replicate the aberrant 184 behavior, or it is not interoperable. This is both a consequence of 185 applying Postel's advice, and a product of a natural reluctance to 186 avoid fatal error conditions. Ensuring interoperability in this 187 environment is often colloquially referred to as aiming to be "bug 188 for bug compatible". 190 For example, in TLS [TLS] extensions use a tag-length-value format, 191 and they can be added to messages in any order. However, some server 192 implementations terminate connections if they encounter a TLS 193 ClientHello message that ends with an empty extension. To maintain 194 interoperability, client implementations are required to be aware of 195 this bug and ensure that a ClientHello message ends in a non-empty 196 extension. 198 The original JSON specification [JSON] demonstrates the effect of 199 specification shortcomings. RFC 4627 omitted critical details on a 200 range of key details including Unicode handling, ordering and 201 duplication of object members, and number encoding. Consequently, a 202 range of interpretations were used by implementations. An updated 203 specification [JSON-BIS] did not correct these errors, concentrating 204 instead on identifying the interoperable subset of JSON. I-JSON 205 [I-JSON] takes that subset and defines a new format that prohibits 206 the problematic parts of JSON. Of course, that means that I-JSON is 207 not fully interoperable with JSON. Consequently, I-JSON is not 208 widely implemented in parsers. Many JSON parsers now implement the 209 more precise algorithm specified in [ECMA262]. 211 The robustness principle therefore encourages a reaction that 212 compounds and entrenches interoperability 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. The cost of building a new implementation increases 222 as the number of implementations and bugs increases. Worse, the set 223 of tweaks necessary for wide interoperability can be difficult to 224 discover. 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 do not 230 interoperate, little prevents those implementations from diverging 231 more over time. 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 reduces 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 Sometimes what appear to be interoperability problems are symptomatic 245 of issues in protocol design. A community that is willing to make 246 changes to the protocol, by revising or extending it, makes the 247 protocol better in the process. Applying the robustness principle 248 might conceal the problem. That can make it harder, or even 249 impossible, to fix later. 251 A similar class of problems is described in RFC 5704 [UNCOORDINATED], 252 which addresses conflict or competition in the maintenance of 253 protocols. This document concerns itself primarily with the absence 254 of maintenance, though the problems are similar. 256 5. Active Protocol Maintenance 258 The robustness principle can be highly effective in safeguarding 259 against flaws in the implementation of a protocol by peers. 260 Especially when a specification remains unchanged for an extended 261 period of time, the inclination to be tolerant accumulates over time. 262 Indeed, when faced with divergent interpretations of an immutable 263 specification, the best way for an implementation to remain 264 interoperable is to be tolerant of differences in interpretation and 265 an occasional outright implementation error. 267 From this perspective, application of Postel's advice to the 268 implementation of a protocol specification that does not change is 269 logical, even necessary. But that suggests that the problem is with 270 the assumption that the situation - existing specifications and 271 implementations - are unable to change. 273 As already established, this is not sustainable. For a protocol to 274 be viable, it is necessary for both specifications and 275 implementations to be responsive to changes, in addition to handling 276 new and old problems that might arise over time. 278 Active maintenance of a protocol is critical in ensuring that 279 specifications correctly reflect the requirements for 280 interoperability. Maintenance enables both new implementations and 281 the continued improvement of the protocol. New use cases are an 282 indicator that the protocol could be successful [SUCCESS]. 284 Protocol designers are strongly encouraged to continue to maintain 285 and evolve protocols beyond their initial inception and definition. 286 Involvement of protocol implementers is a critical part of this 287 process, as they provide input on their experience with 288 implementation and deployment of the protocol. 290 Most interoperability problems do not require revision of protocols 291 or protocol specifications. For instance, the most effective means 292 of dealing with a defective implementation in a peer could be to 293 email the developer of the stack. It is far more efficient in the 294 long term to fix one isolated bug than it is to deal with the 295 consequences of workarounds. 297 Neglect can quickly produce the negative consequences this document 298 describes. Restoring the protocol to a state where it can be 299 maintained involves first discovering the properties of the protocol 300 as it is deployed, rather than the protocol as it was originally 301 documented. This can be difficult and time-consuming, particularly 302 if the protocol has a diverse set of implementations. Such a process 303 was undertaken for HTTP [HTTP] after a period of minimal maintenance. 304 Restoring HTTP specifications to currency took significant effort. 306 6. Extensibility 308 Good extensibility [EXT] can make it easier to respond to new use 309 cases or changes in the environment in which the protocol is 310 deployed. 312 Extensibility is sometimes mistaken for an application of the 313 robustness principle. After all, if one party wants to start using a 314 new feature before another party is prepared to receive it, it might 315 be assumed that the receiving party is being tolerant of unexpected 316 inputs. 318 A well-designed extensibility mechanism establishes clear rules for 319 the handling of things like new messages or parameters. If an 320 extension mechanism is designed and implemented correctly, the user 321 of a new protocol feature can confidently predict the effect that 322 feature will have on existing implementations. 324 Relying on implementations consistently applying the robustness 325 principle is not a good strategy for extensibility. Using 326 undocumented or accidental features of a protocol as the basis of an 327 extensibility mechanism can be extremely difficult, as is 328 demonstrated by the case study in Appendix A.3 of [EXT]. 330 A protocol could be designed to permit a narrow set of valid inputs, 331 or it could allow a wide range of inputs as a core feature (see for 332 example [HTML]). Specifying and implementing a more flexible 333 protocol is more difficult; allowing less variation is preferable in 334 the absence of strong reasons to be flexible. 336 7. The Role of Feedback 338 Protocol maintenance is only possible if there is sufficient 339 information about the deployment of the protocol. Feedback from 340 deployment is critical to effective protocol maintenance. 342 For a protocol specification, the primary and most effective form of 343 feedback comes from people who implement and deploy the protocol. 344 This comes in the form of new requirements, or in experience with the 345 protocol as it is deployed. 347 Managing and deploying changes to implementations can be expensive. 348 However, it is widely recognized that regular updates are a vital 349 part of the deployment of computer systems for security reasons (see 350 for example [IOTSU]). 352 7.1. Feedback from Implementations 354 Automated error reporting mechanisms in protocol implementations 355 allows for better feedback from deployments. Exposing faults through 356 operations and management systems is highly valuable, but it might be 357 necessary to ensure that the information is propagated further. 359 Building telemetry and error logging systems that report faults to 360 the developers of the implementation is superior in many respects. 361 However, this is only possible in deployments that are conducive to 362 the collection of this type of information. Giving due consideration 363 to protection of the privacy of protocol participants is critical 364 prior to deploying any such system. 366 7.2. Virtuous Intolerance 368 A well-specified protocol includes rules for consistent handling of 369 aberrant conditions. This increases the changes that implementations 370 have interoperable handling of unusual conditions. 372 Intolerance of any deviation from specification, where 373 implementations generate fatal errors in response to observing 374 undefined or unusal behaviour, can be harnessed to reduce occurrences 375 of aberrant implementations. Choosing to generate fatal errors for 376 unspecified conditions instead of attempting error recovery can 377 ensure that faults receive attention. 379 This improves feedback for new implementations in particular. When a 380 new implementation encounters a virtuously intolerant implementation, 381 it receives strong feedback that allows problems to be discovered 382 quickly. 384 To be effective, virtuously intolerant implementations need to be 385 sufficiently widely deployed that they are encountered by new 386 implementations with high probability. This could depend on multiple 387 implementations of strict checks. Any intolerance also needs to be 388 strongly supported by specifications, otherwise they encourage 389 fracturing of the protocol community or proliferation of workarounds. 391 Virtuous intolerance can be used to motivate compliance with any 392 protocol requirement. For instance, the INADEQUATE_SECURITY error 393 code and associated requirements in HTTP/2 [HTTP2] resulted in 394 improvements in the security of the deployed base. 396 8. Security Considerations 398 Sloppy implementations, lax interpretations of specifications, and 399 uncoordinated extrapolation of requirements to cover gaps in 400 specification can result in security problems. Hiding the 401 consequences of protocol variations encourages the hiding of issues, 402 which can conceal bugs and make them difficult to discover. 404 The consequences of the problems described in this document are 405 especially acute for any protocol where security depends on agreement 406 about semantics of protocol elements. 408 9. IANA Considerations 410 This document has no IANA actions. 412 10. Informative References 414 [ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th 415 Edition, June 2018, . 418 [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 419 Considerations for Protocol Extensions", RFC 6709, 420 DOI 10.17487/RFC6709, September 2012, 421 . 423 [HOSTS] Braden, R., Ed., "Requirements for Internet Hosts - 424 Communication Layers", STD 3, RFC 1122, 425 DOI 10.17487/RFC1122, October 1989, 426 . 428 [HTML] "HTML", WHATWG Living Standard, March 2019, 429 . 431 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 432 Protocol (HTTP/1.1): Message Syntax and Routing", 433 RFC 7230, DOI 10.17487/RFC7230, June 2014, 434 . 436 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 437 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 438 DOI 10.17487/RFC7540, May 2015, 439 . 441 [I-JSON] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 442 DOI 10.17487/RFC7493, March 2015, 443 . 445 [IOTSU] Tschofenig, H. and S. Farrell, "Report from the Internet 446 of Things Software Update (IoTSU) Workshop 2016", 447 RFC 8240, DOI 10.17487/RFC8240, September 2017, 448 . 450 [IP] Postel, J., "DoD standard Internet Protocol", RFC 760, 451 DOI 10.17487/RFC0760, January 1980, 452 . 454 [JSON] Crockford, D., "The application/json Media Type for 455 JavaScript Object Notation (JSON)", RFC 4627, 456 DOI 10.17487/RFC4627, July 2006, 457 . 459 [JSON-BIS] 460 Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 461 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 462 2014, . 464 [PRINCIPLES] 465 Carpenter, B., Ed., "Architectural Principles of the 466 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 467 . 469 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 470 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 471 . 473 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 474 (TLS) Protocol Version 1.2", RFC 5246, 475 DOI 10.17487/RFC5246, August 2008, 476 . 478 [UNCOORDINATED] 479 Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 480 Protocol Development Considered Harmful", RFC 5704, 481 DOI 10.17487/RFC5704, November 2009, 482 . 484 Appendix A. Acknowledgments 486 Constructive feedback on this document has been provided by a 487 surprising number of people including Bernard Aboba, Brian Carpenter, 488 Mark Nottingham, Russ Housley, Henning Schulzrinne, Robert Sparks, 489 Brian Trammell, and Anne Van Kesteren. Please excuse any omission. 491 Author's Address 493 Martin Thomson 494 Mozilla 496 Email: mt@lowentropy.net