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