idnits 2.17.1 draft-iab-use-it-or-lose-it-00.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 (July 30, 2019) is 1703 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TLS' is mentioned on line 621, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-02 -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. 'HTTP') (Obsoleted by RFC 9110, RFC 9112) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-10 -- Obsolete informational reference (is this intentional?): RFC 7233 (ref. 'HTTP-RANGE') (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. 'MPTCP') (Obsoleted by RFC 8684) == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-20 == Outdated reference: A later version (-13) exists of draft-ietf-quic-invariants-06 -- Obsolete informational reference (is this intentional?): RFC 988 (Obsoleted by RFC 1054, RFC 1112) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 793 (ref. 'TCP') (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 8 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 July 30, 2019 5 Expires: January 31, 2020 7 Long-term Viability of Protocol Extension Mechanisms 8 draft-iab-use-it-or-lose-it-00 10 Abstract 12 The ability to change protocols depends on exercising the extension 13 and version negotiation mechanisms that support change. Protocols 14 that don't use these mechanisms can find that deploying changes can 15 be difficult and costly. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 31, 2020. 34 Copyright Notice 36 Copyright (c) 2019 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Implementations of Protocols are Imperfect . . . . . . . . . 3 53 2.1. Good Protocol Design is Not Itself Sufficient . . . . . . 3 54 2.2. Examples of Disuse . . . . . . . . . . . . . . . . . . . 4 55 2.3. Multi-Party Interactions and Middleboxes . . . . . . . . 5 56 3. Retaining Viable Protocol Evolution Mechanisms . . . . . . . 6 57 3.1. Examples of Active Use . . . . . . . . . . . . . . . . . 7 58 3.2. Dependency is Better . . . . . . . . . . . . . . . . . . 7 59 3.3. Unused Extension Points Become Unusable . . . . . . . . . 8 60 4. Defensive Design Principles for Protocols . . . . . . . . . . 9 61 4.1. Active Use . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.2. Cryptography . . . . . . . . . . . . . . . . . . . . . . 9 63 4.3. Grease . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.4. Invariants . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.5. Effective Feedback . . . . . . . . . . . . . . . . . . . 11 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 68 7. Informative References . . . . . . . . . . . . . . . . . . . 12 69 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 72 1. Introduction 74 A successful protocol [SUCCESS] will change in ways that allow it to 75 continue to fulfill the needs of its users. New use cases, 76 conditions and constraints on the deployment of a protocol can render 77 a protocol that does not change obsolete. 79 Usage patterns and requirements for a protocol shift over time. In 80 response, implementations might adjust usage patterns within the 81 constraints of the protocol, the protocol could be extended, or a 82 replacement protocol might be developed. Experience with Internet- 83 scale protocol deployment shows that each option comes with different 84 costs. [TRANSITIONS] examines the problem of protocol evolution more 85 broadly. 87 This document examines the specific conditions that determine whether 88 protocol maintainers have the ability to design and deploy new or 89 modified protocols. Section 2 highlights some historical issues with 90 difficulties in transitions to new protocol features. Section 3 91 argues that ossified protocols are more difficult to update and 92 successful protocols make frequent use of new extensions and code- 93 points. Section 4 outlines several strategies that might aid in 94 ensuring that protocol changes remain possible over time. 96 The experience that informs this document is predominantly at 97 "higher" layers of the network stack, in protocols that operate at 98 very large scale and Internet-scale applications. It is possible 99 that these conclusions are less applicable to protocol deployments 100 that have less scale and diversity, or operate under different 101 constraints. 103 2. Implementations of Protocols are Imperfect 105 A change to a protocol can be made extremely difficult to deploy if 106 there are bugs in implementations with which the new deployment needs 107 to interoperate. Bugs in the handling of new codepoints or 108 extensions can mean that instead of handling the mechanism as 109 designed, endpoints react poorly. This can manifest as abrupt 110 termination of sessions, errors, crashes, or disappearances of 111 endpoints and timeouts. 113 Interoperability with other implementations is usually highly valued, 114 so deploying mechanisms that trigger adverse reactions can be 115 untenable. Where interoperability is a competitive advantage, this 116 is true even if the negative reactions happen infrequently or only 117 under relatively rare conditions. 119 Deploying a change to a protocol could require implementations fix a 120 substantial proportion of the bugs that the change exposes. This can 121 involve a difficult process that includes identifying the cause of 122 these errors, finding the responsible implementation(s), coordinating 123 a bug fix and release plan, contacting users and/or the operator of 124 affected services, and waiting for the fix to be deployed. 126 Given the effort involved in fixing problems, the existence of these 127 sorts of bugs can outright prevent the deployment of some types of 128 protocol changes, especially for protocols involving multiple parties 129 or that are considered critical infrastructure (e.g., IP, BGP, DNS, 130 or TLS). It could even be necessary to come up with a new protocol 131 design that uses a different method to achieve the same result. 133 The set of interoperable features in a protocol is often the subset 134 of its features that have some value to those implementing and 135 deploying the protocol. It is not always the case that future 136 extensibility is in that set. 138 2.1. Good Protocol Design is Not Itself Sufficient 140 It is often argued that the design of a protocol extension point or 141 version negotiation capability is critical to the freedom that it 142 ultimately offers. 144 RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered 145 advice on designing for extension. It includes the following advice: 147 This means that, to be useful, a protocol version- negotiation 148 mechanism should be simple enough that it can reasonably be 149 assumed that all the implementers of the first protocol version at 150 least managed to implement the version-negotiation mechanism 151 correctly. 153 This has proven to be insufficient in practice. Many protocols have 154 evidence of imperfect implementation of critical mechanisms of this 155 sort. Mechanisms that aren't used are the ones that fail most often. 156 The same paragraph from RFC 6709 acknowledges the existence of this 157 problem, but does not offer any remedy: 159 The nature of protocol version-negotiation mechanisms is that, by 160 definition, they don't get widespread real-world testing until 161 _after_ the base protocol has been deployed for a while, and its 162 deficiencies have become evident. 164 Indeed, basic interoperability is considered critical early in the 165 deployment of a protocol. A desire to deploy can result in an 166 engineering practice that values simplicity, which could result in 167 deferring implementation of version negotiation and extension 168 mechanisms. This leads to these mechanisms being uniquely affected 169 by this problem. 171 2.2. Examples of Disuse 173 Transport Layer Security (TLS) [TLS12] provides examples of where a 174 design that is objectively sound fails when incorrectly implemented. 175 TLS provides examples of failures in protocol version negotiation and 176 extensibility. 178 Version negotiation in TLS 1.2 and earlier uses the "Highest mutually 179 supported version (HMSV)" scheme exactly as it is described in 180 [EXTENSIBILITY]. However, clients are unable to advertise a new 181 version without causing a non-trivial proportions of sessions to fail 182 due to bugs in server and middlebox implementations. 184 Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 185 1.3 [TLS13] has abandoned HMSV version negotiation for a new 186 mechanism. 188 The server name indication (SNI) [TLS-EXT] in TLS is another 189 excellent example of the failure of a well-designed extensibility 190 point. SNI uses the same technique for extension that is used with 191 considerable success in other parts of the TLS protocol. The 192 original design of SNI includes the ability to include multiple names 193 of different types. 195 What is telling in this case is that SNI was defined with just one 196 type of name: a domain name. No other type has ever been 197 standardized, though several have been proposed. Despite an 198 otherwise exemplary design, SNI is so inconsistently implemented that 199 any hope for using the extension point it defines has been abandoned 200 [SNI]. 202 Ossified DNS code bases and systems resulted in fears that new 203 Resource Record Codes (RRCodes) would take years of software 204 propagation before new RRCodes could be used. The result for a long 205 time was heavily overloaded use of the TXT record, such as in the 206 Sender Policy Framework [SPF]. It wasn't until after the standard 207 mechanism for dealing with new RRCodes [RRTYPE] was considered widely 208 deployed that new RRCodes can be safely created and used. 210 As a counter example, the first version of the Simple Network 211 Management Protocol (SNMP) [SNMPv1] defines that unparseable or 212 unauthenticated messages are simply discarded without response: 214 It then verifies the version number of the SNMP message. If there 215 is a mismatch, it discards the datagram and performs no further 216 actions. 218 When SNMP versions 2, 2c and 3 came along, older agents did exactly 219 what the protocol specifies. Deployment of new versions was likely 220 successful because the handling of newer versions was both clear and 221 simple. 223 2.3. Multi-Party Interactions and Middleboxes 225 Even the most superficially simple protocols can often involve more 226 actors than is immediately apparent. A two-party protocol has two 227 ends, but even at the endpoints of an interaction, protocol elements 228 can be passed on to other entities in ways that can affect protocol 229 operation. 231 One of the key challenges in deploying new features is ensuring 232 compatibility with all actors that could be involved in the protocol. 234 Protocols deployed without active measures against intermediation 235 will tend to become intermediated over time, as network operators 236 deploy middleboxes to perform some function on traffic 237 [PATH-SIGNALS]. In particular, one of the consequences of an 238 unencrypted protocol is that any element on path can interact with 239 the protocol. For example, HTTP was specifically designed with 240 intermediation in mind, transparent proxies [HTTP] are not only 241 possible but sometimes advantageous, despite some significant 242 downsides. Consequently, transparent proxies for cleartext HTTP are 243 commonplace. The DNS protocol was designed with intermediation in 244 mind through its use of caching recursive resolvers [DNS]. What was 245 less anticipated was the forced spoofing of DNS records by many 246 middle-boxes such as those that inject authentication or pay-wall 247 mechanisms as an authentication and authorization check, which are 248 now prevalent in hotels, coffee shops and business networks. 250 Middleboxes are also protocol participants, to the degree that they 251 are able to observe and act in ways that affect the protocol. The 252 degree to which a middlebox participates varies from the basic 253 functions that a router performs to full participation. For example, 254 a SIP back-to-back user agent (B2BUA) [B2BUA] can be very deeply 255 involved in the SIP protocol. 257 This phenomenon appears at all layers of the protocol stack, even 258 when protocols are not designed with middlebox participation in mind. 259 TCP's [TCP] extension points have been rendered difficult to use, 260 largely due to middlebox interactions, as experience with Multipath 261 TCP [MPTCP] and Fast Open [TFO] has shown. IP's version field was 262 rendered useless when encapsulated over Ethernet, requring a new 263 ethertype with IPv6 [RFC2462], due in part to layer 2 devices making 264 version-independent assumptions about the structure of the IPv4 265 header. 267 By increasing the number of different actors involved in any single 268 protocol exchange, the number of potential implementation bugs that a 269 deployment needs to contend with also increases. In particular, 270 incompatible changes to a protocol that might be negotiated between 271 endpoints in ignorance of the presence of a middlebox can result in a 272 middlebox interfering in negative and unexpected ways. 274 Unfortunately, middleboxes can considerably increase the difficulty 275 of deploying new versions or other changes to a protocol. 277 3. Retaining Viable Protocol Evolution Mechanisms 279 The design of a protocol for extensibility and eventual replacement 280 [EXTENSIBILITY] does not guarantee the ability to exercise those 281 options. The set of features that enable future evolution need to be 282 interoperable in the first implementations and deployments of the 283 protocol. Implementations of mechanisms that support evolution is 284 necessary to ensure that they remain available for new uses, and 285 history has shown this occurs almost exclusively under active 286 mechanism use. 288 The conditions for retaining the ability to evolve a design is most 289 clearly evident in the protocols that are known to have viable 290 version negotiation or extension points. The definition of 291 mechanisms alone is insufficient; it's the assured implementation 292 through active use of those mechanisms that determines the existence 293 of freedom. Protocols that routinely add new extensions and code 294 points rarely have trouble adding additional ones, especially when 295 the handling of new versions or extension is well defined. 297 3.1. Examples of Active Use 299 For example, header fields in email [SMTP], HTTP [HTTP] and SIP [SIP] 300 all derive from the same basic design, which amounts to a list name/ 301 value pairs. There is no evidence of significant barriers to 302 deploying header fields with new names and semantics in email and 303 HTTP as clients and servers can ignore headers they do not understand 304 or need. The widespread deployment of SIP B2BUAs means that new SIP 305 header fields do not reliably reach peers, however, which doesn't 306 necessarily cause interoperability issues but rather causes feature 307 deployment issues due to the lack of option passing Section 2.3. 309 As another example, the attribute-value pairs (AVPs) in Diameter 310 [DIAMETER] are fundamental to the design of the protocol. Any use of 311 Diameter requires exercising the ability to add new AVPs. This is 312 routinely done without fear that the new feature might not be 313 successfully deployed. 315 These examples show extension points that are heavily used are also 316 being relatively unaffected by deployment issues preventing addition 317 of new values for new use cases. 319 These examples also confirm the case that good design does not 320 guarantee success. On the contrary, success is often despite 321 shortcomings in the design. For instance, the shortcomings of HTTP 322 header fields are significant enough that there are ongoing efforts 323 to improve the syntax [HTTP-HEADERS]. 325 Only by using a protocol's extension capabilities does it ensure the 326 availability of that capability. Protocols that fail to use a 327 mechanism, or a protocol that only rarely uses a mechanism, may 328 suffer an inability to rely on that mechanism. 330 3.2. Dependency is Better 332 The best way to guarantee that a protocol mechanism is used is to 333 make the understanding of it critical to an endpoint participating in 334 that protocol. This means that implementations must rely on both the 335 existence of extension mechanisms and their continued, repeated 336 expansion over time. 338 For example, the message format in SMTP relies on header fields for 339 most of its functions, including the most basic delivery functions. 340 A deployment of SMTP cannot avoid including an implementation of 341 header field handling. In addition to this, the regularity with 342 which new header fields are defined and used ensures that deployments 343 frequently encounter header fields that it does not yet (and may 344 never) understand. An SMTP implementation therefore needs to be able 345 to both process header fields that it understands and ignore those 346 that it does not. 348 In this way, implementing the extensibility mechanism is not merely 349 mandated by the specification, it is crucial to the functioning of a 350 protocol deployment. Should an implementation fail to correctly 351 implement the mechanism, that failure would quickly become apparent. 353 Caution is advised to avoid assuming that building a dependency on an 354 extension mechanism is sufficient to ensure availability of that 355 mechanism in the long term. If the set of possible uses is narrowly 356 constrained and deployments do not change over time, implementations 357 might not see new variations or assume a narrower interpretation of 358 what is possible. Those implementations might still exhibit errors 359 when presented with new variations. 361 3.3. Unused Extension Points Become Unusable 363 In contrast, there are many examples of extension points in protocols 364 that have been either completely unused, or their use was so 365 infrequent that they could no longer be relied upon to function 366 correctly. 368 HTTP has a number of very effective extension points in addition to 369 the aforementioned header fields. It also has some examples of 370 extension points that are so rarely used that it is possible that 371 they are not at all usable. Extension points in HTTP that might be 372 unwise to use include the extension point on each chunk in the 373 chunked transfer coding [HTTP], the ability to use transfer codings 374 other than the chunked coding, and the range unit in a range request 375 [HTTP-RANGE]. 377 Even where extension points have multiple valid values, if the set of 378 permitted values does not change over time, there is still a risk 379 that new values are not tolerated by existing implementations. If 380 the set of values for a particular field remains fixed over a long 381 period, some implementations might not correctly handle a new value 382 when it is introduced. For example, implementations of TLS broke 383 when new values of the signature_algorithms extension were 384 introduced. 386 Codepoints that are reserved for future use can be especially 387 problematic. Reserving codepoints without attributing semantics to 388 their use can result in diverse or conflicting semantics being 389 attributed without any hope of interoperability. An example of this 390 is the "class E" address space in IPv4 [RFC0988], which was reserved 391 without assigning any semantics. For protocols that can use 392 negotiation to attribute semantics to codepoints, it is possible that 393 unused codepoints can be reclaimed for active use, though this 394 requires that the negotiation include all protocol participants. 396 4. Defensive Design Principles for Protocols 398 There are several potential approaches that can provide some measure 399 of protection against a protocol deployment becoming resistant to 400 future changes. 402 4.1. Active Use 404 As discussed in Section 3, the most effective defense against 405 ossification of protocol extension points is active use. 407 Implementations are most likely to be tolerant of new values if they 408 depend on being able to frequently use new values. Failing that, 409 implementations that routinely see new values are more likely to 410 correctly handle new values. More frequent changes will improve the 411 likelihood that incorrect handling or intolerance is discovered and 412 rectified. The longer an intolerant implementation is deployed, the 413 more difficult it is to correct. 415 What active use means can depend greatly on the environment in which 416 a protocol is deployed. The frequency of changes necessary to 417 safeguard some mechanisms might be slow enough to attract 418 ossification in another protocol deployment, while being excessive in 419 others. There are currently no firm guidelines for new protocol 420 development. 422 4.2. Cryptography 424 Cryptography can be used to reduce the number of middlebox entities 425 that can participate in a protocol. Using tools like TLS ensures 426 that only authorized participants are able to influence whether a new 427 protocol feature is used. 429 Permitting fewer protocol participants reduces the number of 430 implementations that can prevent a new mechanism from being deployed. 432 As recommended in [PATH-SIGNALS], use of encryption and integrity 433 protection can be used to limit participation. 435 For example, the QUIC protocol [QUIC] adopts both encryption and 436 integrity protection. Encryption is used to carefully control what 437 information is exposed to middleboxes. For those fields that are not 438 encrypted, QUIC uses integrity protection to prevent modification. 440 4.3. Grease 442 "Grease" [GREASE] identifies lack of use as an issue (protocol 443 mechanisms "rusting" shut) and proposes reserving values for 444 extensions that have no semantic value attached. 446 The design in [GREASE] is aimed at the style of negotiation most used 447 in TLS, where the client offers a set of options and the server 448 chooses the one that it most prefers from those that it supports. A 449 client that uses grease randomly offers options - usually just one - 450 from a set of reserved values. These values are guaranteed to never 451 be assigned real meaning, so the server will never have cause to 452 genuinely select one of these values. 454 More generally, greasing is used to refer to any attempt to exercise 455 extension points without changing endpoint behavior, other than to 456 encourage participants to tolerate new or varying values of protocol 457 elements. 459 The principle that grease operates on is that an implementation that 460 is regularly exposed to unknown values is less likely to be 461 intolerant of new values when they appear. This depends largely on 462 the assumption that the difficulty of implementing the extension 463 mechanism correctly is not significantly more effort than 464 implementing code to identify and filter out reserved values. 465 Reserving random or unevenly distributed values for this purpose is 466 thought to further discourage special treatment. 468 Without reserved greasing codepoints, an implementation can use code 469 points from spaces used for private or experimental use if such a 470 range exists. In addition to the risk of triggering participation in 471 an unwanted experiment, this can be less effective. Incorrect 472 implementations might still be able to correctly identify these code 473 points and ignore them. 475 In addition to advertising bogus capabilities, an endpoint might also 476 selectively disable non-critical protocol elements to test the 477 ability of peers to handle the absence of certain capabilities. 479 This style of defensive design is limited because it is only 480 superficial. It only exercises a small part of the mechanisms that 481 support extensibility. More critically, it does not easily translate 482 to all forms of extension points. For instance, HMSV negotiation 483 cannot be greased in this fashion. Other techniques might be 484 necessary for protocols that don't rely on the particular style of 485 exchange that is predominant in TLS. 487 Grease is deployed with the intent of quickly revealing errors in 488 implementing the mechanisms it safeguards. Though it has been 489 effective at revealing problems in some cases with TLS, the efficacy 490 of greasing isn't proven more generally. Where implementations are 491 able to tolerate a non-zero error rate in their operation, greasing 492 offers a potential option for safeguarding future extensibility. 493 However, this relies on there being a sufficient proportion of 494 participants that are willing to invest the effort and tolerate the 495 risk of interoperability failures. 497 4.4. Invariants 499 Documenting aspects of the protocol that cannot or will not change as 500 extensions or new versions are added can be a useful exercise. 501 Understanding what aspects of a protocol are invariant can help guide 502 the process of identifying those parts of the protocol that might 503 change. 505 As a means of protecting extensibility, a declaration of protocol 506 invariants is useful only to the extent that protocol participants 507 are willing to allow new uses for the protocol. Like with greasing, 508 protocol participants could still purposefully block the deployment 509 of new features. A protocol that declares protocol invariants relies 510 on implementations understanding and respecting those invariants. 512 Protocol invariants need to be clearly and concisely documented. 513 Including examples of aspects of the protocol that are not invariant, 514 such as the appendix of [QUIC-INVARIANTS], can be used to clarify 515 intent. 517 4.5. Effective Feedback 519 While not a direct means of protecting extensibility mechanisms, 520 feedback systems can be important to discovering problems. 522 Visibility of errors is critical to the success of techniques like 523 grease (see Section 4.3). The grease design is most effective if a 524 deployment has a means of detecting and reporting errors. Ignoring 525 errors could allow problems to become entrenched. 527 Feedback on errors is more important during the development and early 528 deployment of a change. It might also be helpful to disable 529 automatic error recovery methods during development. 531 Automated feedback systems are important for automated systems, or 532 where error recovery is also automated. For instance, connection 533 failures with HTTP alternative services [ALT-SVC] are not permitted 534 to affect the outcome of transactions. An automated feedback system 535 for capturing failures in alternative services is therefore necessary 536 for failures to be detected. 538 How errors are gathered and reported will depend greatly on the 539 nature of the protocol deployment and the entity that receives the 540 report. For instance, end users, developers, and network operations 541 each have different requirements for how error reports are created, 542 managed, and acted upon. 544 Automated delivery of error reports can be critical for rectifying 545 deployment errors as early as possible, such as seen in [DMARC] and 546 [SMTP-TLS-Reporting]. 548 5. Security Considerations 550 The ability to design, implement, and deploy new protocol mechanisms 551 can be critical to security. In particular, it is important to be 552 able to replace cryptographic algorithms over time [AGILITY]. For 553 example, preparing for replacement of weak hash algorithms was made 554 more difficult through misuse [HASH]. 556 6. IANA Considerations 558 This document makes no request of IANA. 560 7. Informative References 562 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 563 Agility and Selecting Mandatory-to-Implement Algorithms", 564 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 565 . 567 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 568 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 569 April 2016, . 571 [B2BUA] Kaplan, H. and V. Pascual, "A Taxonomy of Session 572 Initiation Protocol (SIP) Back-to-Back User Agents", 573 RFC 7092, DOI 10.17487/RFC7092, December 2013, 574 . 576 [DIAMETER] 577 Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 578 Ed., "Diameter Base Protocol", RFC 6733, 579 DOI 10.17487/RFC6733, October 2012, 580 . 582 [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 583 Message Authentication, Reporting, and Conformance 584 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 585 . 587 [DNS] Mockapetris, P., "Domain names - concepts and facilities", 588 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 589 . 591 [EXTENSIBILITY] 592 Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 593 Considerations for Protocol Extensions", RFC 6709, 594 DOI 10.17487/RFC6709, September 2012, 595 . 597 [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", 598 draft-ietf-tls-grease-02 (work in progress), January 2019. 600 [HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash 601 Algorithm", Proceedings of NDSS '06 , 2006, 602 . 604 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 605 Protocol (HTTP/1.1): Message Syntax and Routing", 606 RFC 7230, DOI 10.17487/RFC7230, June 2014, 607 . 609 [HTTP-HEADERS] 610 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 611 draft-ietf-httpbis-header-structure-10 (work in progress), 612 April 2019. 614 [HTTP-RANGE] 615 Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 616 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 617 RFC 7233, DOI 10.17487/RFC7233, June 2014, 618 . 620 [INTOLERANCE] 621 Kario, H., "Re: [TLS] Thoughts on Version Intolerance", 622 July 2016, . 625 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 626 "TCP Extensions for Multipath Operation with Multiple 627 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 628 . 630 [PATH-SIGNALS] 631 Hardie, T., "Transport Protocol Path Signals", draft-iab- 632 path-signals-03 (work in progress), January 2019. 634 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 635 and Secure Transport", draft-ietf-quic-transport-20 (work 636 in progress), April 2019. 638 [QUIC-INVARIANTS] 639 Thomson, M., "Version-Independent Properties of QUIC", 640 draft-ietf-quic-invariants-06 (work in progress), July 641 2019. 643 [RFC0988] Deering, S., "Host extensions for IP multicasting", 644 RFC 988, DOI 10.17487/RFC0988, July 1986, 645 . 647 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 648 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 649 December 1998, . 651 [RRTYPE] Gustafsson, A., "Handling of Unknown DNS Resource Record 652 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 653 2003, . 655 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 656 A., Peterson, J., Sparks, R., Handley, M., and E. 657 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 658 DOI 10.17487/RFC3261, June 2002, 659 . 661 [SMTP] Resnick, P., Ed., "Internet Message Format", RFC 5322, 662 DOI 10.17487/RFC5322, October 2008, 663 . 665 [SMTP-TLS-Reporting] 666 Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 667 and M. Risher, "SMTP TLS Reporting", RFC 8460, 668 DOI 10.17487/RFC8460, September 2018, 669 . 671 [SNI] Langley, A., "Accepting that other SNI name types will 672 never work", March 2016, 673 . 676 [SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 677 "Simple Network Management Protocol (SNMP)", RFC 1157, 678 DOI 10.17487/RFC1157, May 1990, 679 . 681 [SPF] Kitterman, S., "Sender Policy Framework (SPF) for 682 Authorizing Use of Domains in Email, Version 1", RFC 7208, 683 DOI 10.17487/RFC7208, April 2014, 684 . 686 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 687 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 688 . 690 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 691 RFC 793, DOI 10.17487/RFC0793, September 1981, 692 . 694 [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 695 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 696 . 698 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 699 Extensions: Extension Definitions", RFC 6066, 700 DOI 10.17487/RFC6066, January 2011, 701 . 703 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 704 (TLS) Protocol Version 1.2", RFC 5246, 705 DOI 10.17487/RFC5246, August 2008, 706 . 708 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 709 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 710 . 712 [TRANSITIONS] 713 Thaler, D., Ed., "Planning for Protocol Adoption and 714 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 715 May 2017, . 717 Acknowledgments 719 Wes Hardaker, Mirja Kuehlewind, Mark Nottingham, and Brian Trammell 720 made significant contributions to this document. 722 Author's Address 724 Martin Thomson 725 Mozilla 727 Email: mt@lowentropy.net