idnits 2.17.1 draft-iab-use-it-or-lose-it-01.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 (14 July 2021) is 989 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TLS' is mentioned on line 746, but not defined == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-16 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-messaging-16 -- Obsolete informational reference (is this intentional?): RFC 6824 (ref. 'MPTCP') (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 988 (Obsoleted by RFC 1054, RFC 1112) -- 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 (~~), 4 warnings (==), 5 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 T. Pauly 5 Expires: 15 January 2022 Apple 6 14 July 2021 8 Long-term Viability of Protocol Extension Mechanisms 9 draft-iab-use-it-or-lose-it-01 11 Abstract 13 The ability to change protocols depends on exercising the extension 14 and version negotiation mechanisms that support change. Protocols 15 that don't use these mechanisms can find it difficult and costly to 16 deploy changes. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Discussion of this document takes place on the EDM Program mailing 23 list (edm@iab.org), which is archived at 24 https://mailarchive.ietf.org/arch/browse/edm/. 26 Source for this draft and an issue tracker can be found at 27 https://github.com/intarchboard/use-it-or-lose-it. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on 15 January 2022. 46 Copyright Notice 48 Copyright (c) 2021 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 53 license-info) in effect on the date of publication of this document. 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. Code Components 56 extracted from this document must include Simplified BSD License text 57 as described in Section 4.e of the Trust Legal Provisions and are 58 provided without warranty as described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Imperfect Implementations Limit Protocol Evolution . . . . . 3 64 2.1. Good Protocol Design is Not Itself Sufficient . . . . . . 4 65 2.2. Disuse Can Hide Problems . . . . . . . . . . . . . . . . 5 66 2.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.2.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 2.2.3. SNMP . . . . . . . . . . . . . . . . . . . . . . . . 6 69 2.2.4. HTTP . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.2.5. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.3. Multi-Party Interactions and Middleboxes . . . . . . . . 7 72 3. Retaining Viable Protocol Evolution Mechanisms . . . . . . . 8 73 3.1. Examples of Active Use . . . . . . . . . . . . . . . . . 9 74 3.2. Dependency is Better . . . . . . . . . . . . . . . . . . 9 75 3.3. Restoring Active Use . . . . . . . . . . . . . . . . . . 10 76 4. Active Use . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.1. Version Negotiation . . . . . . . . . . . . . . . . . . . 11 78 4.2. Falsifying Active Use . . . . . . . . . . . . . . . . . . 11 79 5. Complementary Techniques . . . . . . . . . . . . . . . . . . 13 80 5.1. Cryptography . . . . . . . . . . . . . . . . . . . . . . 13 81 5.2. Fewer Extension Points . . . . . . . . . . . . . . . . . 13 82 5.2.1. Invariants . . . . . . . . . . . . . . . . . . . . . 14 83 5.3. Effective Feedback . . . . . . . . . . . . . . . . . . . 14 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 8. Informative References . . . . . . . . . . . . . . . . . . . 15 87 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 19 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Introduction 92 A successful protocol [SUCCESS] needs to change in ways that allow it 93 to continue to fulfill the needs of its users. New use cases, 94 conditions and constraints on the deployment of a protocol can render 95 a protocol that does not change obsolete. 97 Usage patterns and requirements for a protocol shift over time. In 98 response, implementations might adjust usage patterns within the 99 constraints of the protocol, the protocol could be extended, or a 100 replacement protocol might be developed. Experience with Internet- 101 scale protocol deployment shows that each option comes with different 102 costs. [TRANSITIONS] examines the problem of protocol evolution more 103 broadly. 105 This document examines the specific conditions that determine whether 106 protocol maintainers have the ability to design and deploy new or 107 modified protocols. Section 2 highlights some historical examples of 108 difficulties in transitions to new protocol features. Section 3 109 argues that ossified protocols are more difficult to update and 110 successful protocols make frequent use of new extensions and code- 111 points. Section 4 and Section 5 outline several strategies that 112 might aid in ensuring that protocol changes remain possible over 113 time. 115 The experience that informs this document is predominantly at 116 "higher" layers of the network stack, in protocols that operate at 117 very large scale and Internet-scale applications. It is possible 118 that these conclusions are less applicable to protocol deployments 119 that have less scale and diversity, or operate under different 120 constraints. 122 2. Imperfect Implementations Limit Protocol Evolution 124 It can be extremely difficult to deploy a change to a protocol if 125 there are bugs in implementations with which the new deployment needs 126 to interoperate. Bugs in how new codepoints or extensions are 127 handled often mean that endpoints will react poorly to the use of 128 extension mechanisms. This can manifest as abrupt termination of 129 sessions, errors, crashes, or disappearances of endpoints and 130 timeouts. 132 Interoperability with other implementations is usually highly valued, 133 so deploying mechanisms that trigger adverse reactions can be 134 untenable. Where interoperability is a competitive advantage, this 135 is true even if the negative reactions happen infrequently or only 136 under relatively rare conditions. 138 Deploying a change to a protocol could require implementations fix a 139 substantial proportion of the bugs that the change exposes. This can 140 involve a difficult process that includes identifying the cause of 141 these errors, finding the responsible implementation(s), coordinating 142 a bug fix and release plan, contacting users and/or the operator of 143 affected services, and waiting for the fix to be deployed. 145 Given the effort involved in fixing problems, the existence of these 146 sorts of bugs can outright prevent the deployment of some types of 147 protocol changes, especially for protocols involving multiple parties 148 or that are considered critical infrastructure (e.g., IP, BGP, DNS, 149 or TLS). It could even be necessary to come up with a new protocol 150 design that uses a different method to achieve the same result. 152 The set of interoperable features in a protocol is often the subset 153 of its features that have some value to those implementing and 154 deploying the protocol. It is not always the case that future 155 extensibility is in that set. 157 2.1. Good Protocol Design is Not Itself Sufficient 159 It is often argued that the careful design of a protocol extension 160 point or version negotiation capability is critical to the freedom 161 that it ultimately offers. 163 RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered 164 advice on designing for extension. It includes the following advice: 166 This means that, to be useful, a protocol version-negotiation 167 mechanism should be simple enough that it can reasonably be 168 assumed that all the implementers of the first protocol version at 169 least managed to implement the version-negotiation mechanism 170 correctly. 172 This has proven to be insufficient in practice. Many protocols have 173 evidence of imperfect implementation of critical mechanisms of this 174 sort. Mechanisms that aren't used are the ones that fail most often. 175 The same paragraph from RFC 6709 acknowledges the existence of this 176 problem, but does not offer any remedy: 178 The nature of protocol version-negotiation mechanisms is that, by 179 definition, they don't get widespread real-world testing until 180 _after_ the base protocol has been deployed for a while, and its 181 deficiencies have become evident. 183 Indeed, basic interoperability is considered critical early in the 184 deployment of a protocol. A desire to deploy can result in an 185 engineering practice that values simplicity, which could result in 186 deferring implementation of version negotiation and extension 187 mechanisms. This leads to these mechanisms being particularly 188 affected by this problem. 190 2.2. Disuse Can Hide Problems 192 There are many examples of extension points in protocols that have 193 been either completely unused, or their use was so infrequent that 194 they could no longer be relied upon to function correctly. 196 2.2.1. TLS 198 Transport Layer Security (TLS) [TLS12] provides examples of where a 199 design that is objectively sound fails when incorrectly implemented. 200 TLS provides examples of failures in protocol version negotiation and 201 extensibility. 203 Version negotiation in TLS 1.2 and earlier uses the "Highest mutually 204 supported version (HMSV)" scheme exactly as it is described in 205 [EXTENSIBILITY]. However, clients are unable to advertise a new 206 version without causing a non-trivial proportions of sessions to fail 207 due to bugs in server and middlebox implementations. 209 Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 210 1.3 [TLS13] has abandoned HMSV version negotiation for a new 211 mechanism. 213 The server name indication (SNI) [TLS-EXT] in TLS is another 214 excellent example of the failure of a well-designed extensibility 215 point. SNI uses the same technique for extension that is used with 216 considerable success in other parts of the TLS protocol. The 217 original design of SNI includes the ability to include multiple names 218 of different types. 220 What is telling in this case is that SNI was defined with just one 221 type of name: a domain name. No other type has ever been 222 standardized, though several have been proposed. Despite an 223 otherwise exemplary design, SNI is so inconsistently implemented that 224 any hope for using the extension point it defines has been abandoned 225 [SNI]. 227 Even where extension points have multiple valid values, if the set of 228 permitted values does not change over time, there is still a risk 229 that new values are not tolerated by existing implementations. If 230 the set of values for a particular field remains fixed over a long 231 period, some implementations might not correctly handle a new value 232 when it is introduced. For example, implementations of TLS broke 233 when new values of the signature_algorithms extension were 234 introduced. 236 2.2.2. DNS 238 Ossified DNS code bases and systems resulted in fears that new 239 Resource Record Codes (RRCodes) would take years of software 240 propagation before new RRCodes could be used. The result for a long 241 time was heavily overloaded use of the TXT record, such as in the 242 Sender Policy Framework [SPF]. It wasn't until after the standard 243 mechanism for dealing with new RRCodes [RRTYPE] was considered widely 244 deployed that new RRCodes can be safely created and used. 246 2.2.3. SNMP 248 As a counter example, the first version of the Simple Network 249 Management Protocol (SNMP) [SNMPv1] defines that unparseable or 250 unauthenticated messages are simply discarded without response: 252 It then verifies the version number of the SNMP message. If there 253 is a mismatch, it discards the datagram and performs no further 254 actions. 256 When SNMP versions 2, 2c and 3 came along, older agents did exactly 257 what the protocol specifies. Deployment of new versions was likely 258 successful because the handling of newer versions was both clear and 259 simple. 261 2.2.4. HTTP 263 HTTP has a number of very effective extension points in addition to 264 the aforementioned header fields. It also has some examples of 265 extension points that are so rarely used that it is possible that 266 they are not at all usable. 268 Extension points in HTTP that might be unwise to use include the 269 extension point on each chunk in the chunked transfer coding 270 Section 7.1 of [HTTP11], the ability to use transfer codings other 271 than the chunked coding, and the range unit in a range request 272 Section 14 of [HTTP]. 274 2.2.5. IPv4 276 Codepoints that are reserved for future use can be especially 277 problematic. Reserving codepoints without attributing semantics to 278 their use can result in diverse or conflicting semantics being 279 attributed without any hope of interoperability. An example of this 280 is the "class E" address space in IPv4 [RFC0988], which was reserved 281 without assigning any semantics. 283 For protocols that can use negotiation to attribute semantics to 284 codepoints, it is possible that unused codepoints can be reclaimed 285 for active use, though this requires that the negotiation include all 286 protocol participants. For something as fundamental as addressing, 287 negotiation is difficult or even impossible, as all nodes on the 288 network path plus potential alternative paths would need to be 289 involved. 291 2.3. Multi-Party Interactions and Middleboxes 293 Even the most superficially simple protocols can often involve more 294 actors than is immediately apparent. A two-party protocol has two 295 ends, but even at the endpoints of an interaction, protocol elements 296 can be passed on to other entities in ways that can affect protocol 297 operation. 299 One of the key challenges in deploying new features is ensuring 300 compatibility with all actors that could be involved in the protocol. 302 Protocols deployed without active measures against intermediation 303 will tend to become intermediated over time, as network operators 304 deploy middleboxes to perform some function on traffic 305 [PATH-SIGNALS]. In particular, one of the consequences of an 306 unencrypted protocol is that any element on path can interact with 307 the protocol. For example, HTTP was specifically designed with 308 intermediation in mind, transparent proxies [HTTP] are not only 309 possible but sometimes advantageous, despite some significant 310 downsides. Consequently, transparent proxies for cleartext HTTP are 311 commonplace. The DNS protocol was designed with intermediation in 312 mind through its use of caching recursive resolvers [DNS]. What was 313 less anticipated was the forced spoofing of DNS records by many 314 middle-boxes such as those that inject authentication or pay-wall 315 mechanisms as an authentication and authorization check, which are 316 now prevalent in hotels, coffee shops and business networks. 318 Middleboxes are also protocol participants, to the degree that they 319 are able to observe and act in ways that affect the protocol. The 320 degree to which a middlebox participates varies from the basic 321 functions that a router performs to full participation. For example, 322 a SIP back-to-back user agent (B2BUA) [B2BUA] can be very deeply 323 involved in the SIP protocol. 325 This phenomenon appears at all layers of the protocol stack, even 326 when protocols are not designed with middlebox participation in mind. 327 TCP's [TCP] extension points have been rendered difficult to use, 328 largely due to middlebox interactions, as experience with Multipath 329 TCP [MPTCP] and Fast Open [TFO] has shown. IP's version field was 330 rendered useless when encapsulated over Ethernet, requring a new 331 ethertype with IPv6 [RFC2464], due in part to layer 2 devices making 332 version-independent assumptions about the structure of the IPv4 333 header. The announcements of new optional transitive attributes in 334 BGP caused significant routing instability [RIPE-99]. 336 By increasing the number of different actors involved in any single 337 protocol exchange, the number of potential implementation bugs that a 338 deployment needs to contend with also increases. In particular, 339 incompatible changes to a protocol that might be negotiated between 340 endpoints in ignorance of the presence of a middlebox can result in a 341 middlebox interfering in negative and unexpected ways. 343 Unfortunately, middleboxes can considerably increase the difficulty 344 of deploying new versions or other changes to a protocol. 346 3. Retaining Viable Protocol Evolution Mechanisms 348 The design of a protocol for extensibility and eventual replacement 349 [EXTENSIBILITY] does not guarantee the ability to exercise those 350 options. The set of features that enable future evolution need to be 351 interoperable in the first implementations and deployments of the 352 protocol. Implementations of mechanisms that support evolution is 353 necessary to ensure that they remain available for new uses, and 354 history has shown this occurs almost exclusively through active 355 mechanism use. 357 The conditions for retaining the ability to evolve a design is most 358 clearly evident in the protocols that are known to have viable 359 version negotiation or extension points. The definition of 360 mechanisms alone is insufficient; it's the assured implementation 361 through active use of those mechanisms that determines the existence 362 of freedom. Protocols that routinely add new extensions and code 363 points rarely have trouble adding additional ones, especially when 364 the handling of new versions or extension is well defined. 366 3.1. Examples of Active Use 368 For example, header fields in email [SMTP], HTTP [HTTP] and SIP [SIP] 369 all derive from the same basic design, which amounts to a list name/ 370 value pairs. There is no evidence of significant barriers to 371 deploying header fields with new names and semantics in email and 372 HTTP as clients and servers can ignore headers they do not understand 373 or need. The widespread deployment of SIP B2BUAs means that new SIP 374 header fields do not reliably reach peers, however, which doesn't 375 necessarily cause interoperability issues but rather causes feature 376 deployment issues due to the lack of option passing Section 2.3. 378 As another example, the attribute-value pairs (AVPs) in Diameter 379 [DIAMETER] are fundamental to the design of the protocol. Any use of 380 Diameter requires exercising the ability to add new AVPs. This is 381 routinely done without fear that the new feature might not be 382 successfully deployed. 384 These examples show extension points that are heavily used are also 385 being relatively unaffected by deployment issues preventing addition 386 of new values for new use cases. 388 These examples also confirm the case that good design does not 389 guarantee success. On the contrary, success is often despite 390 shortcomings in the design. For instance, the shortcomings of HTTP 391 header fields are significant enough that there are ongoing efforts 392 to improve the syntax [HTTP-HEADERS]. 394 Only by using a protocol's extension capabilities does it ensure the 395 availability of that capability. Protocols that fail to use a 396 mechanism, or a protocol that only rarely uses a mechanism, may 397 suffer an inability to rely on that mechanism. 399 3.2. Dependency is Better 401 The best way to guarantee that a protocol mechanism is used is to 402 make the handling of it critical to an endpoint participating in that 403 protocol. This means that implementations must rely on both the 404 existence of extension mechanisms and their continued, repeated 405 expansion over time. 407 For example, the message format in SMTP relies on header fields for 408 most of its functions, including the most basic delivery functions. 409 A deployment of SMTP cannot avoid including an implementation of 410 header field handling. In addition to this, the regularity with 411 which new header fields are defined and used ensures that deployments 412 frequently encounter header fields that it does not yet (and may 413 never) understand. An SMTP implementation therefore needs to be able 414 to both process header fields that it understands and ignore those 415 that it does not. 417 In this way, implementing the extensibility mechanism is not merely 418 mandated by the specification, it is crucial to the functioning of a 419 protocol deployment. Should an implementation fail to correctly 420 implement the mechanism, that failure would quickly become apparent. 422 Caution is advised to avoid assuming that building a dependency on an 423 extension mechanism is sufficient to ensure availability of that 424 mechanism in the long term. If the set of possible uses is narrowly 425 constrained and deployments do not change over time, implementations 426 might not see new variations or assume a narrower interpretation of 427 what is possible. Those implementations might still exhibit errors 428 when presented with new variations. 430 3.3. Restoring Active Use 432 With enough effort, active use can be used to restore capabililities. 434 EDNS [EDNS] was defined to provide extensibility in DNS. Intolerance 435 of the extension in DNS servers resulted in a fallback method being 436 widely deployed (see Section 6.2.2 of [EDNS]), This fallback resulted 437 in EDNS being disabled for affected servers. Over time, greater 438 support for EDNS and increased reliance on it for different features 439 motivated a flag day [DNSFLAGDAY] where the workaround was removed. 441 The EDNS example shows that effort can be used to restore 442 capabilities. This is in part because EDNS was actively used with 443 most resolvers and servers. It was therefore possible to force a 444 change to ensure that extension capabilities would always be 445 available. However, this required an enormous coordination effort. 446 A small number of incompatible servers and the names they serve also 447 become inaccessible to most clients. 449 4. Active Use 451 As discussed in Section 3, the most effective defense against 452 ossification of protocol extension points is active use. 454 Implementations are most likely to be tolerant of new values if they 455 depend on being able to frequently use new values. Failing that, 456 implementations that routinely see new values are more likely to 457 correctly handle new values. More frequent changes will improve the 458 likelihood that incorrect handling or intolerance is discovered and 459 rectified. The longer an intolerant implementation is deployed, the 460 more difficult it is to correct. 462 What constitutes "active use" can depend greatly on the environment 463 in which a protocol is deployed. The frequency of changes necessary 464 to safeguard some mechanisms might be slow enough to attract 465 ossification in another protocol deployment, while being excessive in 466 others. 468 4.1. Version Negotiation 470 As noted in Section 2.1, protocols that provide version negotiation 471 mechanisms might not be able to test that feature until a new version 472 is deployed. One relatively successful design approach has been to 473 use the protocol selection mechanisms built into a lower-layer 474 protocol to select the protocol. This could allow a version 475 negotiation mechanism to benefit from active use of the extension 476 point by other protocols. 478 For instance, all published versions of IP contain a version number 479 as the four high bits of the first header byte. However, version 480 selection using this field proved to be unsuccessful. Ultimately, 481 successful deployment of IPv6 over Ethernet [RFC2464] required a 482 different EtherType from IPv4. This change took advantage of the 483 already-diverse usage of EtherType. 485 Other examples of this style of design include Application-Layer 486 Protocol Negotiation ([ALPN]) and HTTP content negotiation 487 (Section 12 of [HTTP]). 489 This technique relies on the codepoint being usable. For instance, 490 the IP protocol number is known to be unreliable and therefore not 491 suitable [NEW-PROTOCOLS]. 493 4.2. Falsifying Active Use 495 "Grease" was originally defined for TLS [GREASE], but has been 496 adopted by other protocols, such as QUIC [QUIC]. Grease identifies 497 lack of use as an issue (protocol mechanisms "rusting" shut) and 498 proposes reserving values for extensions that have no semantic value 499 attached. 501 The design in [GREASE] is aimed at the style of negotiation most used 502 in TLS, where one endpoint offers a set of options and the other 503 chooses the one that it most prefers from those that it supports. An 504 endpoint that uses grease randomly offers options - usually just one 505 - from a set of reserved values. These values are guaranteed to 506 never be assigned real meaning, so its peer will never have cause to 507 genuinely select one of these values. 509 More generally, greasing is used to refer to any attempt to exercise 510 extension points without changing endpoint behavior, other than to 511 encourage participants to tolerate new or varying values of protocol 512 elements. 514 The principle that grease operates on is that an implementation that 515 is regularly exposed to unknown values is less likely to be 516 intolerant of new values when they appear. This depends largely on 517 the assumption that the difficulty of implementing the extension 518 mechanism correctly is as easy or easier than implementing code to 519 identify and filter out reserved values. Reserving random or 520 unevenly distributed values for this purpose is thought to further 521 discourage special treatment. 523 Without reserved greasing codepoints, an implementation can use code 524 points from spaces used for private or experimental use if such a 525 range exists. In addition to the risk of triggering participation in 526 an unwanted experiment, this can be less effective. Incorrect 527 implementations might still be able to identify these code points and 528 ignore them. 530 In addition to advertising bogus capabilities, an endpoint might also 531 selectively disable non-critical protocol elements to test the 532 ability of peers to handle the absence of certain capabilities. 534 This style of defensive design is limited because it is only 535 superficial. As greasing only mimics active use of an extension 536 point, it only exercises a small part of the mechanisms that support 537 extensibility. More critically, it does not easily translate to all 538 forms of extension points. For instance, HMSV negotiation cannot be 539 greased in this fashion. Other techniques might be necessary for 540 protocols that don't rely on the particular style of exchange that is 541 predominant in TLS. 543 Grease is deployed with the intent of quickly revealing errors in 544 implementing the mechanisms it safeguards. Though it has been 545 effective at revealing problems in some cases with TLS, the efficacy 546 of greasing isn't proven more generally. Where implementations are 547 able to tolerate a non-zero error rate in their operation, greasing 548 offers a potential option for safeguarding future extensibility. 550 However, this relies on there being a sufficient proportion of 551 participants that are willing to invest the effort and tolerate the 552 risk of interoperability failures. 554 5. Complementary Techniques 556 The protections to protocol evolution that come from active use 557 (Section 4) can be improved through the use of other defensive 558 techniques. The techniques listed here might not prevent 559 ossification on their own, but can make active use more effective. 561 5.1. Cryptography 563 Cryptography can be used to reduce the number of middlebox entities 564 that can participate in a protocol or limit the extent of 565 participation. Using TLS or other cryptographic tools can therefore 566 reduce the number of entities that can influence whether new features 567 are usable. 569 [PATH-SIGNALS] recommends the use of encryption and integrity 570 protection to limit participation. For example, encryption is used 571 by the QUIC protocol [QUIC] to limit the information that is 572 available to middleboxes and integrity protection prevents 573 modification. 575 5.2. Fewer Extension Points 577 A successful protocol will include many potential types of extension. 578 Designing multiple types of extension mechanism, each suited to a 579 specific purpose, might leave some extension points less heavily used 580 than others. 582 Disuse of a specialized extension point might render it unusable. In 583 contrast, having a smaller number of extension points with wide 584 applicability could improve the use of those extension points. Use 585 of a shared extension point for any purpose can protect rarer or more 586 specialized uses. 588 Both extensions and core protocol elements use the same extension 589 points in protocols like HTTP [HTTP] and DIAMETER [DIAMETER]; see 590 Section 3.1. 592 5.2.1. Invariants 594 Documenting aspects of the protocol that cannot or will not change as 595 extensions or new versions are added can be a useful exercise. 596 Understanding what aspects of a protocol are invariant can help guide 597 the process of identifying those parts of the protocol that might 598 change. 600 As a means of protecting extensibility, a declaration of protocol 601 invariants is useful only to the extent that protocol participants 602 are willing to allow new uses for the protocol. Like with greasing, 603 protocol participants could still purposefully block the deployment 604 of new features. A protocol that declares protocol invariants relies 605 on implementations understanding and respecting those invariants. 607 Protocol invariants need to be clearly and concisely documented. 608 Including examples of aspects of the protocol that are not invariant, 609 such as the appendix of [QUIC-INVARIANTS], can be used to clarify 610 intent. 612 5.3. Effective Feedback 614 While not a direct means of protecting extensibility mechanisms, 615 feedback systems can be important to discovering problems. 617 Visibility of errors is critical to the success of techniques like 618 grease (see Section 4.2). The grease design is most effective if a 619 deployment has a means of detecting and reporting errors. Ignoring 620 errors could allow problems to become entrenched. 622 Feedback on errors is more important during the development and early 623 deployment of a change. It might also be helpful to disable 624 automatic error recovery methods during development. 626 Automated feedback systems are important for automated systems, or 627 where error recovery is also automated. For instance, connection 628 failures with HTTP alternative services [ALT-SVC] are not permitted 629 to affect the outcome of transactions. An automated feedback system 630 for capturing failures in alternative services is therefore necessary 631 for failures to be detected. 633 How errors are gathered and reported will depend greatly on the 634 nature of the protocol deployment and the entity that receives the 635 report. For instance, end users, developers, and network operations 636 each have different requirements for how error reports are created, 637 managed, and acted upon. 639 Automated delivery of error reports can be critical for rectifying 640 deployment errors as early as possible, such as seen in [DMARC] and 641 [SMTP-TLS-Reporting]. 643 6. Security Considerations 645 Many of the problems identified in this document are not the result 646 of deliberate actions by an adversary, but more the result of 647 mistakes, decisions made without sufficient context, or simple 648 neglect. Problems therefore not the result of opposition by an 649 adversary. In response, the recommended measures generally assume 650 that other protocol participants will not take deliberate action to 651 prevent protocol evolution. 653 The use of cryptographic techniques to exclude potential participants 654 is the only strong measure that the document recommends. However, 655 authorized protocol peers are most often responsible for the 656 identified problems, which can mean that cryptography is insufficient 657 to exclude them. 659 The ability to design, implement, and deploy new protocol mechanisms 660 can be critical to security. In particular, it is important to be 661 able to replace cryptographic algorithms over time [AGILITY]. For 662 example, preparing for replacement of weak hash algorithms was made 663 more difficult through misuse [HASH]. 665 7. IANA Considerations 667 This document makes no request of IANA. 669 8. Informative References 671 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 672 Agility and Selecting Mandatory-to-Implement Algorithms", 673 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 674 . 676 [ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, 677 "Transport Layer Security (TLS) Application-Layer Protocol 678 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 679 July 2014, . 681 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 682 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 683 April 2016, . 685 [B2BUA] Kaplan, H. and V. Pascual, "A Taxonomy of Session 686 Initiation Protocol (SIP) Back-to-Back User Agents", 687 RFC 7092, DOI 10.17487/RFC7092, December 2013, 688 . 690 [DIAMETER] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 691 Ed., "Diameter Base Protocol", RFC 6733, 692 DOI 10.17487/RFC6733, October 2012, 693 . 695 [DMARC] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based 696 Message Authentication, Reporting, and Conformance 697 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, 698 . 700 [DNS] Mockapetris, P., "Domain names - concepts and facilities", 701 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 702 . 704 [DNSFLAGDAY] 705 "DNS Flag Day 2019", May 2019, 706 . 708 [EDNS] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 709 for DNS (EDNS(0))", STD 75, RFC 6891, 710 DOI 10.17487/RFC6891, April 2013, 711 . 713 [EXTENSIBILITY] 714 Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 715 Considerations for Protocol Extensions", RFC 6709, 716 DOI 10.17487/RFC6709, September 2012, 717 . 719 [GREASE] Benjamin, D., "Applying Generate Random Extensions And 720 Sustain Extensibility (GREASE) to TLS Extensibility", 721 RFC 8701, DOI 10.17487/RFC8701, January 2020, 722 . 724 [HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash 725 Algorithm", Proceedings of NDSS '06 , 2006, 726 . 728 [HTTP] Fielding, R. T., Nottingham, M., and J. Reschke, "HTTP 729 Semantics", Work in Progress, Internet-Draft, draft-ietf- 730 httpbis-semantics-16, 27 May 2021, 731 . 734 [HTTP-HEADERS] 735 Nottingham, M. and P-H. Kamp, "Structured Field Values for 736 HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021, 737 . 739 [HTTP11] Fielding, R. T., Nottingham, M., and J. Reschke, 740 "HTTP/1.1", Work in Progress, Internet-Draft, draft-ietf- 741 httpbis-messaging-16, 27 May 2021, 742 . 745 [INTOLERANCE] 746 Kario, H., "Re: [TLS] Thoughts on Version Intolerance", 20 747 July 2016, . 750 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 751 "TCP Extensions for Multipath Operation with Multiple 752 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 753 . 755 [NEW-PROTOCOLS] 756 Barik, R., Welzl, M., Fairhurst, G., Elmokashfi, A., 757 Dreibholz, T., and S. Gjessing, "On the usability of 758 transport protocols other than TCP: A home gateway and 759 internet path traversal study", Computer Networks Vol. 760 173, pp. 107211, DOI 10.1016/j.comnet.2020.107211, May 761 2020, . 763 [PATH-SIGNALS] 764 Wendt, C. and M. Barnes, "Personal Assertion Token 765 (PaSSporT) Extension for Signature-based Handling of 766 Asserted information using toKENs (SHAKEN)", RFC 8588, 767 DOI 10.17487/RFC8588, May 2019, 768 . 770 [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 771 Multiplexed and Secure Transport", RFC 9000, 772 DOI 10.17487/RFC9000, May 2021, 773 . 775 [QUIC-INVARIANTS] 776 Thomson, M., "Version-Independent Properties of QUIC", 777 RFC 8999, DOI 10.17487/RFC8999, May 2021, 778 . 780 [RFC0988] Deering, S., "Host extensions for IP multicasting", 781 RFC 988, DOI 10.17487/RFC0988, July 1986, 782 . 784 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 785 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 786 . 788 [RIPE-99] Romijn, E., "RIPE NCC and Duke University BGP Experiment", 789 27 August 2010, . 792 [RRTYPE] Gustafsson, A., "Handling of Unknown DNS Resource Record 793 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 794 2003, . 796 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 797 A., Peterson, J., Sparks, R., Handley, M., and E. 798 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 799 DOI 10.17487/RFC3261, June 2002, 800 . 802 [SMTP] Resnick, P., Ed., "Internet Message Format", RFC 5322, 803 DOI 10.17487/RFC5322, October 2008, 804 . 806 [SMTP-TLS-Reporting] 807 Margolis, D., Brotman, A., Ramakrishnan, B., Jones, J., 808 and M. Risher, "SMTP TLS Reporting", RFC 8460, 809 DOI 10.17487/RFC8460, September 2018, 810 . 812 [SNI] Langley, A., "Accepting that other SNI name types will 813 never work", 3 March 2016, 814 . 817 [SNMPv1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, 818 "Simple Network Management Protocol (SNMP)", RFC 1157, 819 DOI 10.17487/RFC1157, May 1990, 820 . 822 [SPF] Kitterman, S., "Sender Policy Framework (SPF) for 823 Authorizing Use of Domains in Email, Version 1", RFC 7208, 824 DOI 10.17487/RFC7208, April 2014, 825 . 827 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 828 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 829 . 831 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 832 RFC 793, DOI 10.17487/RFC0793, September 1981, 833 . 835 [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 836 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 837 . 839 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 840 Extensions: Extension Definitions", RFC 6066, 841 DOI 10.17487/RFC6066, January 2011, 842 . 844 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 845 (TLS) Protocol Version 1.2", RFC 5246, 846 DOI 10.17487/RFC5246, August 2008, 847 . 849 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 850 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 851 . 853 [TRANSITIONS] 854 Thaler, D., Ed., "Planning for Protocol Adoption and 855 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 856 May 2017, . 858 Acknowledgments 860 Wes Hardaker, Mirja Kuehlewind, Mark Nottingham, and Brian Trammell 861 made significant contributions to this document. 863 Authors' Addresses 865 Martin Thomson 866 Mozilla 868 Email: mt@lowentropy.net 870 Tommy Pauly 871 Apple 873 Email: tpauly@apple.com