idnits 2.17.1 draft-iab-protocol-maintenance-05.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 (12 July 2021) is 1012 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) == Outdated reference: A later version (-04) exists of draft-iab-use-it-or-lose-it-00 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 6 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 12 July 2021 5 Expires: 13 January 2022 7 The Harmful Consequences of the Robustness Principle 8 draft-iab-protocol-maintenance-05 10 Abstract 12 The robustness principle, often phrased as "be conservative in what 13 you send, and liberal in what you accept", has long guided the design 14 and implementation of Internet protocols. The posture this statement 15 advocates promotes interoperability in the short term, but can 16 negatively affect the protocol ecosystem over time. For a protocol 17 that is actively maintained, the robustness principle can, and 18 should, be avoided. 20 Note to Readers 22 Discussion of this document takes place on the Architecture-Discuss 23 mailing list (architecture-discuss@ietf.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/architecture-discuss/ 25 (https://mailarchive.ietf.org/arch/browse/architecture-discuss/). 27 Source for this draft and an issue tracker can be found at 28 https://github.com/intarchboard/protocol-maintenance 29 (https://github.com/intarchboard/protocol-maintenance). 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on 13 January 2022. 48 Copyright Notice 50 Copyright (c) 2021 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 55 license-info) in effect on the date of publication of this document. 56 Please review these documents carefully, as they describe your rights 57 and restrictions with respect to this document. Code Components 58 extracted from this document must include Simplified BSD License text 59 as described in Section 4.e of the Trust Legal Provisions and are 60 provided without warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 65 2. Fallibility of Specifications . . . . . . . . . . . . . . . . 3 66 3. Protocol Decay . . . . . . . . . . . . . . . . . . . . . . . 4 67 4. Ecosystem Effects . . . . . . . . . . . . . . . . . . . . . . 5 68 5. Active Protocol Maintenance . . . . . . . . . . . . . . . . . 6 69 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 70 7. Virtuous Intolerance . . . . . . . . . . . . . . . . . . . . 8 71 8. Exclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 11. Informative References . . . . . . . . . . . . . . . . . . . 10 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 The robustness principle has been hugely influential in shaping the 81 design of the Internet. As stated in IAB RFC 1958 [PRINCIPLES], the 82 robustness principle advises to: 84 Be strict when sending and tolerant when receiving. 85 Implementations must follow specifications precisely when sending 86 to the network, and tolerate faulty input from the network. When 87 in doubt, discard faulty input silently, without returning an 88 error message unless this is required by the specification. 90 This simple statement captures a significant concept in the design of 91 interoperable systems. Many consider the application of the 92 robustness principle to be instrumental in the success of the 93 Internet as well as the design of interoperable protocols in general. 95 Time and experience shows that negative consequences to 96 interoperability accumulate over time if implementations apply the 97 robustness principle. This problem originates from an assumption 98 implicit in the principle that it is not possible to affect change in 99 a system the size of the Internet. That is, the idea that once a 100 protocol specification is published, changes that might require 101 existing implementations to change are not feasible. 103 Many problems that might lead to applications of the robustness 104 principle are avoided for protocols under active maintenance. Active 105 protocol maintenance is where a community of protocol designers, 106 implementers, and deployers work together to continuously improve and 107 evolve protocol specifications alongside implementations and 108 deployments of those protocols. A community that takes an active 109 role in the maintenance of protocols can greatly reduce and even 110 eliminate opportunities to apply the robustness principle. 112 There is good evidence to suggest that many important protocols are 113 routinely maintained beyond their inception. In particular, a 114 sizeable proportion of IETF activity is dedicated to the stewardship 115 of existing protocols. This document serves primarily as a record of 116 the hazards inherent in applying the robustness principle and to 117 offer an alternative strategy for handling interoperability problems 118 in deployments. 120 Ideally, protocol implementations never have to apply the robustness 121 principle. Or, where it is unavoidable, use of the robustness 122 principle is viewed as a short term workaround that needs to be 123 quickly reverted. 125 2. Fallibility of Specifications 127 The context from which the robustness principle was developed 128 provides valuable insights into its intent and purpose. The earliest 129 form of the principle in the RFC series (in RFC 760 [IP]) is preceded 130 by a sentence that reveals the motivation for the principle: 132 While the goal of this specification is to be explicit about the 133 protocol there is the possibility of differing interpretations. 134 In general, an implementation should be conservative in its 135 sending behavior, and liberal in its receiving behavior. 137 This formulation of the principle expressly recognizes the 138 possibility that the specification could be imperfect. This 139 contextualizes the principle in an important way. 141 An imperfect specification is natural, largely because it is more 142 important to proceed to implementation and deployment than it is to 143 perfect a specification. A protocol, like any complex system, 144 benefits greatly from experience with its use. A deployed protocol 145 is immeasurably more useful than a perfect protocol. The robustness 146 principle is a tool that is suited to early phases of system design. 148 As [SUCCESS] demonstrates, success or failure of a protocol depends 149 far more on factors like usefulness than on on technical excellence. 150 Timely publication of protocol specifications, even with the 151 potential for flaws, likely contributed significantly to the eventual 152 success of the Internet. 154 The problem is therefore not with the premise, but with its 155 conclusion: the robustness principle itself. 157 3. Protocol Decay 159 The application of the robustness principle to the early Internet, or 160 any system that is in early phases of deployment, is expedient. 161 Applying the principle defers the effort of dealing with 162 interoperability problems, which prioritizes progress. However, 163 deferral can amplify the ultimate cost of handling interoperability 164 problems. 166 Divergent implementations of a specification emerge over time. When 167 variations occur in the interpretation or expression of semantic 168 components, implementations cease to be perfectly interoperable. 170 Implementation bugs are often identified as the cause of variation, 171 though it is often a combination of factors. Application of a 172 protocol to uses that were not anticipated in the original design, or 173 ambiguities and errors in the specification are often confounding 174 factors. Disagreements on the interpretation of specifications 175 should be expected over the lifetime of a protocol. 177 Even with the best intentions, the pressure to interoperate can be 178 significant. No implementation can hope to avoid having to trade 179 correctness for interoperability indefinitely. 181 An implementation that reacts to variations in the manner recommended 182 in the robustness principle sets up a feedback cycle. Over time: 184 * Implementations progressively add logic to constrain how data is 185 transmitted, or to permit variations in what is received. 187 * Errors in implementations or confusion about semantics are 188 permitted or ignored. 190 * These errors can become entrenched, forcing other implementations 191 to be tolerant of those errors. 193 A flaw can become entrenched as a de facto standard. Any 194 implementation of the protocol is required to replicate the aberrant 195 behavior, or it is not interoperable. This is both a consequence of 196 applying the robustness principle, and a product of a natural 197 reluctance to avoid fatal error conditions. Ensuring 198 interoperability in this environment is often referred to as aiming 199 to be "bug for bug compatible". 201 For example, in TLS [TLS] extensions use a tag-length-value format, 202 and they can be added to messages in any order. However, some server 203 implementations terminate connections if they encounter a TLS 204 ClientHello message that ends with an empty extension. To maintain 205 interoperability, client implementations are required to be aware of 206 this bug and ensure that a ClientHello message ends in a non-empty 207 extension. 209 The original JSON specification [JSON] demonstrates the effect of 210 specification shortcomings. RFC 4627 omitted critical details on a 211 range of key details including Unicode handling, ordering and 212 duplication of object members, and number encoding. Consequently, a 213 range of interpretations were used by implementations. An updated 214 specification [JSON-BIS] did not correct these errors, concentrating 215 instead on identifying the interoperable subset of JSON. I-JSON 216 [I-JSON] takes that subset and defines a new format that prohibits 217 the problematic parts of JSON. Of course, that means that I-JSON is 218 not fully interoperable with JSON. Consequently, I-JSON is not 219 widely implemented in parsers. Many JSON parsers now implement the 220 more precise algorithm specified in [ECMA262]. 222 The robustness principle therefore encourages a reaction that can 223 create interoperability problems. In particular, the application of 224 the robustness principle is particularly deleterious for early 225 implementations of new protocols as quirks in early implementations 226 can affect all subsequent deployments. 228 4. Ecosystem Effects 230 Once deviations become entrenched, it can be extremely difficult - if 231 not impossible - to rectify the situation. 233 Interoperability requirements for protocol implementations are set by 234 other deployments. Specifications and - where they exist - 235 conformance test suites might guide the initial development of 236 implementations, but implementations ultimately need to interoperate 237 with deployed implementations. 239 For widely used protocols, the massive scale of the Internet makes 240 large-scale interoperability testing infeasible for all but a 241 privileged few. The cost of building a new implementation using 242 reverse engineering increases as the number of implementations and 243 bugs increases. Worse, the set of tweaks necessary for wide 244 interoperability can be difficult to discover. 246 Consequently, new implementations might be forced into niche uses, 247 where the problems arising from interoperability issues can be more 248 closely managed. However, restricting new implementations into 249 limited deployments risks causing forks in the protocol. If 250 implementations do not interoperate, little prevents those 251 implementations from diverging more over time. 253 This has a negative impact on the ecosystem of a protocol. New 254 implementations are important in ensuring the continued viability of 255 a protocol. New protocol implementations are also more likely to be 256 developed for new and diverse use cases and often are the origin of 257 features and capabilities that can be of benefit to existing users. 259 The need to work around interoperability problems also reduces the 260 ability of established implementations to change. An accumulation of 261 mitigations for interoperability issues makes implementations more 262 difficult to maintain and can constrain extensibility (see also 263 [USE-IT]). 265 Sometimes what appear to be interoperability problems are symptomatic 266 of issues in protocol design. A community that is willing to make 267 changes to the protocol, by revising or extending it, makes the 268 protocol better in the process. Applying the robustness principle 269 instead conceals problems, making it harder, or even impossible, to 270 fix them later. 272 5. Active Protocol Maintenance 274 The robustness principle can be highly effective in safeguarding 275 against flaws in the implementation of a protocol by peers. 276 Especially when a specification remains unchanged for an extended 277 period of time, incentive to be tolerant of errors accumulates over 278 time. Indeed, when faced with divergent interpretations of an 279 immutable specification, the only way for an implementation to remain 280 interoperable is to be tolerant of differences in interpretation and 281 implementation errors. 283 From this perspective, application of the robustness principle to the 284 implementation of a protocol specification that does not change is 285 logical, even necessary. But that conclusion relies on an assumption 286 that existing specifications and implementations are unable to 287 change. Applying the robustness principle in this way 288 disproportionately values short-term gains over the negative effects 289 on future implementations and the protocol as a whole. 291 For a protocol to have sustained viability, it is necessary for both 292 specifications and implementations to be responsive to changes, in 293 addition to handling new and old problems that might arise over time. 295 Maintaining specifications so that they closely match deployments 296 ensures that implementations are consistently interoperable and 297 removes needless barriers for new implementations. Maintenance also 298 enables continued improvement of the protocol. New use cases are an 299 indicator that the protocol could be successful [SUCCESS]. 301 Protocol designers are strongly encouraged to continue to maintain 302 and evolve protocol specificationss beyond their initial inception 303 and definition. This might require the development of revised 304 specifications, extensions, or other supporting material that 305 documents the current state of the protocol. Involvement of those 306 who implement and deploy the protocol is a critical part of this 307 process, as they provide input on their experience with how the 308 protocol is used. 310 Most interoperability problems do not require revision of protocols 311 or protocol specifications. For instance, the most effective means 312 of dealing with a defective implementation in a peer could be to 313 email the developer responsible. It is far more efficient in the 314 long term to fix one isolated bug than it is to deal with the 315 consequences of workarounds. 317 Early implementations of protocols have a stronger obligation to 318 closely follow specifications as their behavior will affect all 319 subsequent implementations. In addition to specifications, later 320 implementations will be guided by what existing deployments accept. 321 Tolerance of errors in early deployments is most likely to result in 322 problems. Protocol specifications might need more frequent revision 323 during early deployments to capture feedback from early rounds of 324 deployment. 326 Neglect can quickly produce the negative consequences this document 327 describes. Restoring the protocol to a state where it can be 328 maintained involves first discovering the properties of the protocol 329 as it is deployed, rather than the protocol as it was originally 330 documented. This can be difficult and time-consuming, particularly 331 if the protocol has a diverse set of implementations. Such a process 332 was undertaken for HTTP [HTTP] after a period of minimal maintenance. 333 Restoring HTTP specifications to relevance took significant effort. 335 Maintenance is most effective if it is responsive, which is greatly 336 affected by how rapidly protocol changes can be deployed. For 337 protocol deployments that operate on longer time scales, temporary 338 workarounds following the spirit of the robustness principle might be 339 necessary. If specifications can be updated more readily than 340 deployments, details of the workaround can be documented, including 341 the desired form of the protocols once the need for workarounds no 342 longer exists and plans for removing the workaround. 344 6. Extensibility 346 Good extensibility [EXT] can make it easier to respond to new use 347 cases or changes in the environment in which the protocol is 348 deployed. 350 The ability to extend a protocol is sometimes mistaken for an 351 application of the robustness principle. After all, if one party 352 wants to start using a new feature before another party is prepared 353 to receive it, it might be assumed that the receiving party is being 354 tolerant of unexpected inputs. 356 A well-designed extensibility mechanism establishes clear rules for 357 the handling of things like new messages or parameters. This depends 358 on having clear rules for the handling of malformed or illegal inputs 359 so that implementations behave consistently in all cases that might 360 affect interoperation. If extension mechanisms and error handling 361 are designed and implemented correctly, new protocol features can be 362 deployed with confidence in the understanding of the effect they have 363 on existing implementations. 365 In contrast, relying on implementations to consistently apply the 366 robustness principle is not a good strategy for extensibility. Using 367 undocumented or accidental features of a protocol as the basis of an 368 extensibility mechanism can be extremely difficult, as is 369 demonstrated by the case study in Appendix A.3 of [EXT]. 371 A protocol could be designed to permit a narrow set of valid inputs, 372 or it could allow a wide range of inputs as a core feature (see for 373 example [HTML]). Specifying and implementing a more flexible 374 protocol is more difficult; allowing less variability is preferable 375 in the absence of strong reasons to be flexible. 377 7. Virtuous Intolerance 379 A well-specified protocol includes rules for consistent handling of 380 aberrant conditions. This increases the chances that implementations 381 will have consistent and interoperable handling of unusual 382 conditions. 384 Intolerance of any deviation from specification, where 385 implementations generate fatal errors in response to observing 386 undefined or unusual behaviour, can be harnessed to reduce 387 occurrences of aberrant implementations. Choosing to generate fatal 388 errors for unspecified conditions instead of attempting error 389 recovery can ensure that faults receive attention. 391 This improves feedback for new implementations in particular. When a 392 new implementation encounters a peer that is intolerant of an error, 393 it receives strong feedback that allows the problem to be discovered 394 quickly. 396 To be effective, intolerant implementations need to be sufficiently 397 widely deployed that they are encountered by new implementations with 398 high probability. This could depend on multiple implementations 399 deploying strict checks. 401 This does not mean that intolerance of errors in early deployments of 402 protocols have the effect of preventing interoperability. On the 403 contrary, when existing implementations follow clearly specified 404 error handling, new implementations or features can be introduced 405 more readily as the effect on existing implementations can be easily 406 predicted; see also Section 6. 408 Any intolerance also needs to be strongly supported by 409 specifications, otherwise they encourage fracturing of the protocol 410 community or proliferation of workarounds; see Section 8. 412 Intolerance can be used to motivate compliance with any protocol 413 requirement. For instance, the INADEQUATE_SECURITY error code and 414 associated requirements in HTTP/2 [HTTP2] resulted in improvements in 415 the security of the deployed base. 417 8. Exclusion 419 Any protocol participant that is affected by changes arising from 420 maintenance might be excluded if they are unwilling or unable to 421 implement or deploy changes that are made to the protocol. 423 Deliberate exclusion of problematic implementations is an important 424 tool that can ensure that the interoperability of a protocol remains 425 viable. While compatible changes are always preferable to 426 incompatible ones, it is not always possible to produce a design that 427 protects the ability of all current and future protocol participants 428 to interoperate. Developing and deploying changes that risk 429 exclusion of previously interoperating implementations requires some 430 care, but changes to a protocol should not be blocked on the grounds 431 of the risk of exclusion alone. 433 Exclusion is a direct goal when choosing to be intolerant of errors 434 (see Section 7). Exclusionary actions are employed with the 435 deliberate intent of protecting future interoperability. 437 Excluding implementations or deployments can lead to a fracturing of 438 the protocol system that could be more harmful than any divergence 439 resulting from following the robustness principle. RFC 5704 440 [UNCOORDINATED] describes how conflict or competition in the 441 maintenance of protocols can lead to similar problems. 443 9. Security Considerations 445 Sloppy implementations, lax interpretations of specifications, and 446 uncoordinated extrapolation of requirements to cover gaps in 447 specification can result in security problems. Hiding the 448 consequences of protocol variations encourages the hiding of issues, 449 which can conceal bugs and make them difficult to discover. 451 The consequences of the problems described in this document are 452 especially acute for any protocol where security depends on agreement 453 about semantics of protocol elements. For instance, use of unsafe 454 security mechanisms, such as weak primitives [MD5] or obsolete 455 mechanisms [SSL3], are good examples of where forcing exclusion 456 (Section 8) can be desirable. 458 10. IANA Considerations 460 This document has no IANA actions. 462 11. Informative References 464 [ECMA262] "ECMAScript(R) 2018 Language Specification", ECMA-262 9th 465 Edition, June 2018, . 468 [EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 469 Considerations for Protocol Extensions", RFC 6709, 470 DOI 10.17487/RFC6709, September 2012, 471 . 473 [HTML] "HTML", WHATWG Living Standard, 8 March 2019, 474 . 476 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 477 Protocol (HTTP/1.1): Message Syntax and Routing", 478 RFC 7230, DOI 10.17487/RFC7230, June 2014, 479 . 481 [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 482 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 483 DOI 10.17487/RFC7540, May 2015, 484 . 486 [I-JSON] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 487 DOI 10.17487/RFC7493, March 2015, 488 . 490 [IP] Postel, J., "DoD standard Internet Protocol", RFC 760, 491 DOI 10.17487/RFC0760, January 1980, 492 . 494 [JSON] Crockford, D., "The application/json Media Type for 495 JavaScript Object Notation (JSON)", RFC 4627, 496 DOI 10.17487/RFC4627, July 2006, 497 . 499 [JSON-BIS] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 500 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 501 2014, . 503 [MD5] Turner, S. and L. Chen, "Updated Security Considerations 504 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 505 RFC 6151, DOI 10.17487/RFC6151, March 2011, 506 . 508 [PRINCIPLES] 509 Carpenter, B., Ed., "Architectural Principles of the 510 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, 511 . 513 [SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 514 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 515 DOI 10.17487/RFC7568, June 2015, 516 . 518 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 519 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 520 . 522 [TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol 523 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 524 . 526 [UNCOORDINATED] 527 Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated 528 Protocol Development Considered Harmful", RFC 5704, 529 DOI 10.17487/RFC5704, November 2009, 530 . 532 [USE-IT] Thomson, M., "Long-term Viability of Protocol Extension 533 Mechanisms", Work in Progress, Internet-Draft, draft-iab- 534 use-it-or-lose-it-00, 7 August 2019, 535 . 538 Appendix A. Acknowledgments 540 Constructive feedback on this document has been provided by a 541 surprising number of people including Bernard Aboba, Brian Carpenter, 542 Stuart Cheshire, Mark Nottingham, Russ Housley, Henning Schulzrinne, 543 Robert Sparks, Brian Trammell, and Anne Van Kesteren. Please excuse 544 any omission. 546 Author's Address 548 Martin Thomson 549 Mozilla 551 Email: mt@lowentropy.net