idnits 2.17.1 draft-thomson-use-it-or-lose-it-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 29, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TLS' is mentioned on line 486, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-01 -- 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-06 -- 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-12 -- 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 (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Thomson 3 Internet-Draft Mozilla 4 Intended status: Informational June 29, 2018 5 Expires: December 31, 2018 7 Long-term Viability of Protocol Extension Mechanisms 8 draft-thomson-use-it-or-lose-it-02 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 December 31, 2018. 34 Copyright Notice 36 Copyright (c) 2018 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 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 . . . . . . . . . . . . . . . . . 6 57 3.2. Dependency is Better . . . . . . . . . . . . . . . . . . 7 58 3.3. Unused Extension Points Become Unusable . . . . . . . . . 7 59 4. Defensive Design Principles for Protocols . . . . . . . . . . 8 60 4.1. Active Use . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.2. Grease . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 9 63 4.4. Visibility of Faults . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 66 7. Informative References . . . . . . . . . . . . . . . . . . . 10 67 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 A successful protocol [SUCCESS] will change in ways that allow it to 73 continue to fulfill the needs of its users. New use cases, 74 conditions and constraints on the deployment of a protocol can render 75 a protocol that does not change obsolete. 77 Usage patterns and requirements for a protocol shift over time. 78 Protocols can react to these shifts in one of three ways: adjust 79 usage patterns within the constraints of the protocol, extend the 80 protocol, and replace the protocol. These reactions are 81 progressively more disruptive, but are also dictated by the nature of 82 the change in requirements over longer periods. 84 Experience with Internet-scale protocol deployment shows that 85 changing protocols is not uniformly successful. [TRANSITIONS] 86 examines the problem more broadly. 88 This document examines the specific conditions that determine whether 89 protocol maintainers have the ability to design and deploy new or 90 modified protocols. Section 4 outlines several strategies that might 91 aid in ensuring that protocol changes remain possible over time. 93 2. Implementations of Protocols are Imperfect 95 A change to a protocol can be made extremely difficult to deploy if 96 there are bugs in implementations with which the new deployment needs 97 to interoperate. Bugs in the handling of new codepoints or 98 extensions can mean that instead of handling the mechanism as 99 designed, endpoints react poorly. This can manifest as abrupt 100 termination of sessions, errors, crashes, or disappearances of 101 endpoints and timeouts. 103 Interoperability with other implementations is usually highly valued, 104 so deploying mechanisms that trigger adverse reactions like these can 105 be untenable. Where interoperability is a competitive advantage, 106 this is true even if the negative reactions happen infrequently or 107 only under relatively rare conditions. 109 Deploying a change to a protocol could require fixing a substantial 110 proportion of the bugs that the change exposes. This can involve a 111 difficult process that includes identifying the cause of these 112 errors, finding the responsible implementation, coordinating a bug 113 fix and release plan, contacting the operator of affected services, 114 and waiting for the fix to be deployed to those services. 116 Given the effort involved in fixing these problems, the existence of 117 these sorts of bugs can outright prevent the deployment of some types 118 of protocol changes. It could even be necessary to come up with a 119 new protocol design that uses a different method to achieve the same 120 result. 122 The set of interoperable features in a protocol is often the subset 123 of its features that have some value to those implementing and 124 deploying the protocol. It is not always the case that future 125 extensibility is in that set. 127 2.1. Good Protocol Design is Not Sufficient 129 It is often argued that the design of a protocol extension point or 130 version negotiation capability is critical to the freedom that it 131 ultimately offers. 133 RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered 134 advice on designing for extension. It includes the following advice: 136 This means that, to be useful, a protocol version- negotiation 137 mechanism should be simple enough that it can reasonably be 138 assumed that all the implementers of the first protocol version at 139 least managed to implement the version-negotiation mechanism 140 correctly. 142 This has proven to be insufficient in practice. Many protocols have 143 evidence of imperfect implementation of these critical mechanisms. 144 Mechanisms that aren't used are the ones that fail most often. The 145 same paragraph from RFC 6709 acknowledges the existence of this 146 problem, but does not offer any remedy: 148 The nature of protocol version-negotiation mechanisms is that, by 149 definition, they don't get widespread real-world testing until 150 _after_ the base protocol has been deployed for a while, and its 151 deficiencies have become evident. 153 Indeed, basic interoperability is considered critical early in the 154 deployment of a protocol, and any engineering practice that values 155 simplicity will tend to make version negotiation and extension 156 mechanisms optional for this basic interoperability. This leads to 157 these mechanisms being uniquely affected by this problem. 159 Transport Layer Security (TLS) [TLS12] provides examples of where a 160 design that is objectively sound fails when incorrectly implemented. 161 TLS provides examples of failures in protocol version negotiation and 162 extensibility. 164 Version negotiation in TLS 1.2 and earlier uses the "Highest mutually 165 supported version (HMSV)" scheme exactly as it is described in 166 [EXTENSIBILITY]. However, clients are unable to advertise a new 167 version without causing a non-trivial proportions of sessions to fail 168 due to bugs in server and middlebox implementations. 170 Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 171 1.3 [TLS13] has abandoned HMSV version negotiation for a new 172 mechanism. 174 The server name indication (SNI) [TLS-EXT] in TLS is another 175 excellent example of the failure of a well-designed extensibility 176 point. SNI uses the same technique for extension that is used with 177 considerable success in other parts of the TLS protocol. The 178 original design of SNI includes the ability to include multiple names 179 of different types. 181 What is telling in this case is that SNI was defined with just one 182 type of name: a domain name. No other type has ever been 183 standardized, though several have been proposed. Despite an 184 otherwise exemplary design, SNI is so inconsistently implemented that 185 any hope for using the extension point it defines has been abandoned 186 [SNI]. 188 2.2. Multi-Party Interactions and Middleboxes 190 Even the most superficially simple protocols can often involve more 191 actors than is immediately apparent. A two-party protocol has two 192 ends, but even at the endpoints of an interaction, protocol elements 193 can be passed on to other entities in ways that can affect protocol 194 operation. 196 One of the key challenges in deploying new features in a protocol is 197 ensuring compatibility with all actors that could influence the 198 outcome. 200 Protocols deployed without active measures against intermediation 201 will tend to become intermediated over time, as network operators 202 deploy middleboxes to perform some function on traffic. In 203 particular, one of the consequences of an unencrypted protocol is 204 that any element on path can interact with the protocol. For 205 example, HTTP was specifically designed with intermediation in mind, 206 transparent proxies [HTTP] are not only possible but sometimes 207 advantageous, despite some significant downsides. Consequently, 208 transparent proxies for cleartext HTTP are commonplace. 210 Middleboxes are also protocol participants, to the degree that they 211 are able to observe and act in ways that affect the protocol. The 212 degree to which a middlebox participates varies from the basic 213 functions that a router performs to full participation. For example, 214 a SIP back-to-back user agent (B2BUA) [B2BUA] can be very deeply 215 involved in the SIP protocol. 217 This phenomenon appears at all layers of the protocol stack, even 218 when protocols are not designed with middlebox participation in mind. 219 TCP's [TCP] extension points have been rendered difficult to use, 220 largely due to middlebox interactions, as experience with Multipath 221 TCP [MPTCP] has shown. IP's version field was rendered useless when 222 encapsulated over Ethernet, requring a new ethertype with IPv6 223 [RFC2462], due in part to layer 2 devices making version-independent 224 assumptions about the structure of the IPv4 header. 226 By increasing the number of different actors involved in any single 227 protocol exchange, the number of potential implementation bugs that a 228 deployment needs to contend with also increases. In particular, 229 incompatible changes to a protocol that might be negotiated between 230 endpoints in ignorance of the presence of a middlebox can result in a 231 middlebox acting badly. 233 Thus, middleboxes can increase the difficulty of deploying changes to 234 a protocol considerably. 236 3. Retaining Viable Protocol Evolution Mechanisms 238 The design of a protocol for extensibility and eventual replacement 239 [EXTENSIBILITY] does not guarantee the ability to exercise those 240 options. The set of features that enable future evolution need to be 241 interoperable in the first implementations and deployments of the 242 protocol. Active use of mechanisms that support evolution is the 243 only way to ensure that they remain available for new uses. 245 3.1. Examples of Active Use 247 The conditions for retaining the ability to evolve a design is most 248 clearly evident in the protocols that are known to have viable 249 version negotiation or extension points. The definition of 250 mechanisms alone is insufficient; it's the active use of those 251 mechanisms that determines the existence of freedom. 253 For example, header fields in email [SMTP], HTTP [HTTP] and SIP [SIP] 254 all derive from the same basic design. There is no evidence of 255 significant barriers to deploying header fields with new names and 256 semantics in email and HTTP, though the widespread deployment of SIP 257 B2BUAs means that new SIP header fields can be more difficult. 259 In another example, the attribute-value pairs (AVPs) in Diameter 260 [DIAMETER] are fundamental to the design of the protocol. The 261 definition of new uses of Diameter regularly exercise the ability to 262 add new AVPs and do so with no fear that the new feature might not be 263 successfully deployed. 265 These examples show extension points that are heavily used also being 266 relatively unaffected by deployment issues preventing addition of new 267 values for new use cases. 269 These examples also confirm the case that good design is not a 270 prerequisite for success. On the contrary, success is often despite 271 shortcomings in the design. For instance, the shortcomings of HTTP 272 header fields are significant enough that there are ongoing efforts 273 to improve the syntax [HTTP-HEADERS]. 275 Only using a protocol capability is able to ensure availability of 276 that capability. Protocols that fail to use a mechanism, or a 277 protocol that only rarely uses a mechanism, suffer an inability to 278 rely on that mechanism. 280 3.2. Dependency is Better 282 The best way to guarantee that a protocol mechanism is used is to 283 make it critical to an endpoint participating in that protocol. This 284 means that implementations rely on both the existence of the protocol 285 mechanism and its use. 287 For example, the message format in SMTP relies on header fields for 288 most of its functions, including the most basic functions. A 289 deployment of SMTP cannot avoid including an implementation of header 290 field handling. In addition to this, the regularity with which new 291 header fields are defined and used ensures that deployments 292 frequently encounter header fields that it does not understand. An 293 SMTP implementation therefore needs to be able to both process header 294 fields that it understands and ignore those that it does not. 296 In this way, implementing the extensibility mechanism is not merely 297 mandated by the specification, it is crucial to the functioning of a 298 protocol deployment. Should an implementation fail to correctly 299 implement the mechanism, that failure would quickly become apparent. 301 Caution is advised to avoid assuming that building a dependency on an 302 extension mechanism is sufficient to ensure availability of that 303 mechanism in the long term. If the set of possible uses is narrowly 304 constrained and deployments do not change over time, implementations 305 might not see new variations or assume a narrower interpretation of 306 what is possible. Those implementations might still exhibit errors 307 when presented with a new variation. 309 3.3. Unused Extension Points Become Unusable 311 In contrast, there are many examples of extension points in protocols 312 that have been either completely unused, or their use was so 313 infrequent that they could no longer be relied upon to function 314 correctly. 316 HTTP has a number of very effective extension points in addition to 317 the aforementioned header fields. It also has some examples of 318 extension point that are so rarely used that it is possible that they 319 are not at all usable. Extension points in HTTP that might be unwise 320 to use include the extension point on each chunk in the chunked 321 transfer coding [HTTP], the ability to use transfer codings other 322 than the chunked coding, and the range unit in a range request 323 [HTTP-RANGE]. 325 4. Defensive Design Principles for Protocols 327 There are several potential approaches that can provide some measure 328 of protection against a protocol deployment becoming resistant to 329 change. 331 4.1. Active Use 333 As discussed in Section 3, the most effective defense against misuse 334 of protocol extension points is active use. 336 4.2. Grease 338 "Grease" [GREASE] identifies lack of use as an issue (protocol 339 mechanisms "rusting" shut) and proposes a system of use that 340 exercises extension points by using dummy values. 342 The primary feature of the grease design is aimed at the style of 343 negotiation most used in TLS, where the client offers a set of 344 options and the server chooses the one that it most prefers from 345 those that it supports. A client that uses grease randomly offers 346 options - usually just one - from a set of reserved values. These 347 values are guaranteed to never be assigned real meaning, so the 348 server will never have cause to genuinely select one of these values. 350 The principle that grease operates on is that an implementation that 351 is regularly exposed to unknown values is not likely to become 352 intolerant of new values when they appear. This depends largely on 353 the assumption that the difficulty of implementing the protocol 354 mechanism correctly is not significantly more effort than 355 implementing code to specifically filter out the randomized grease 356 values. 358 To avoid simple techniques for filtering greasing codepoints, grease 359 values are not reserved from a single contiguous block of code 360 points, but are distributed evenly across the entire space of code 361 points. Reserving a randomly selected set of code points has a 362 greater chance of avoiding this problem, though it might be more 363 difficult to specify and implement, especially over larger code point 364 spaces. 366 Without reserved greasing codepoints, an implementation can use code 367 points from spaces used for private or experimental use if such a 368 range exists. In addition to the risk of triggering participation in 369 an unwanted experiment, this can be less effective. Incorrect 370 implementations might still be able to correctly identify these code 371 points and ignore them. 373 Grease is deployed with the intent of quickly detecting errors in 374 implementing the mechanisms it safeguards. 376 This form of defensive design has some limitations. It does not 377 necessarily create the need for an implementation to rely on the 378 mechanism it safeguards; that is determined by the underlying 379 protocol itself. More critically, it does not easily translate to 380 other forms of extension point. For instance, HMSV negotiation 381 cannot be greased in this fashion. Other techniques might be 382 necessary for protocols that don't rely on the particular style of 383 exchange that is predominant in TLS. 385 4.3. Cryptography 387 Cryptography can be used to reduce the number of entities that can 388 participate in a protocol. Using tools like TLS ensures that only 389 authorized participants are able to influence whether a new protocol 390 feature is used. 392 Data that is exchanged under encryption cannot be seen by 393 middleboxes, excluding them from participating in that part of the 394 protocol. Similarly, data that is exchanged with integrity 395 protection cannot be modified without being detected and discarded. 397 The QUIC protocol [QUIC] adopts both encryption and integrity 398 protection. Encryption is used to carefully control what information 399 is exposed to middleboxes. For those fields that are not encrypted, 400 QUIC uses integrity protection to prevent modification. 402 4.4. Visibility of Faults 404 Feedback is critical to the success of the grease technique (see 405 Section 4.2). The system only works if an protocol deployment has a 406 means of detecting and analyzing errors. Ignoring errors could allow 407 those errors to become entrenched. This process can be automated, 408 but when operating at scale it might be difficult or impossible to 409 collect details of specific errors. 411 Feedback on errors is more important during the development and early 412 deployment of a change. Disabling automatic error recovery methods 413 during development improves visibility of errors. 415 Automated feedback systems are important for automated systems, or 416 where error recovery is also automated. For instance, connection 417 failures with HTTP alternative services [ALT-SVC] are not permitted 418 to affect the outcome of transactions. An automated feedback system 419 for capturing failures in alternative services is therefore necessary 420 for failures to be detected. 422 5. Security Considerations 424 The ability to design, implement, and deploy new protocol mechanisms 425 can be critical to security. In particular, it is important to be 426 able to replace cryptographic algorithms over time [AGILITY]. For 427 example, preparing for replacement of weak hash algorithms was made 428 more difficult through misuse [HASH]. 430 6. IANA Considerations 432 This document makes no request of IANA. 434 7. Informative References 436 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 437 Agility and Selecting Mandatory-to-Implement Algorithms", 438 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 439 . 441 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 442 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 443 April 2016, . 445 [B2BUA] Kaplan, H. and V. Pascual, "A Taxonomy of Session 446 Initiation Protocol (SIP) Back-to-Back User Agents", 447 RFC 7092, DOI 10.17487/RFC7092, December 2013, 448 . 450 [DIAMETER] 451 Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 452 Ed., "Diameter Base Protocol", RFC 6733, 453 DOI 10.17487/RFC6733, October 2012, 454 . 456 [EXTENSIBILITY] 457 Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 458 Considerations for Protocol Extensions", RFC 6709, 459 DOI 10.17487/RFC6709, September 2012, 460 . 462 [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", 463 draft-ietf-tls-grease-01 (work in progress), June 2018. 465 [HASH] Bellovin, S. and E. Rescorla, "Deploying a New Hash 466 Algorithm", Proceedings of NDSS '06 , 2006, 467 . 469 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 470 Protocol (HTTP/1.1): Message Syntax and Routing", 471 RFC 7230, DOI 10.17487/RFC7230, June 2014, 472 . 474 [HTTP-HEADERS] 475 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 476 draft-ietf-httpbis-header-structure-06 (work in progress), 477 June 2018. 479 [HTTP-RANGE] 480 Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 481 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 482 RFC 7233, DOI 10.17487/RFC7233, June 2014, 483 . 485 [INTOLERANCE] 486 Kario, H., "Re: [TLS] Thoughts on Version Intolerance", 487 July 2016, . 490 [MPTCP] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 491 "TCP Extensions for Multipath Operation with Multiple 492 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 493 . 495 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 496 and Secure Transport", draft-ietf-quic-transport-12 (work 497 in progress), May 2018. 499 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 500 Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462, 501 December 1998, . 503 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 504 A., Peterson, J., Sparks, R., Handley, M., and E. 505 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 506 DOI 10.17487/RFC3261, June 2002, 507 . 509 [SMTP] Resnick, P., Ed., "Internet Message Format", RFC 5322, 510 DOI 10.17487/RFC5322, October 2008, 511 . 513 [SNI] Langley, A., "Accepting that other SNI name types will 514 never work", March 2016, 515 . 518 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 519 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 520 . 522 [TCP] Postel, J., "Transmission Control Protocol", STD 7, 523 RFC 793, DOI 10.17487/RFC0793, September 1981, 524 . 526 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 527 Extensions: Extension Definitions", RFC 6066, 528 DOI 10.17487/RFC6066, January 2011, 529 . 531 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 532 (TLS) Protocol Version 1.2", RFC 5246, 533 DOI 10.17487/RFC5246, August 2008, 534 . 536 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 537 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 538 March 2018. 540 [TRANSITIONS] 541 Thaler, D., Ed., "Planning for Protocol Adoption and 542 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 543 May 2017, . 545 Acknowledgments 547 Brian Trammell and Mark Nottingham made contributions to this 548 document. 550 Author's Address 552 Martin Thomson 553 Mozilla 555 Email: martin.thomson@gmail.com