idnits 2.17.1 draft-thomson-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 (March 23, 2018) is 2219 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TLS' is mentioned on line 457, but not defined == Outdated reference: A later version (-04) exists of draft-ietf-tls-grease-00 -- 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-04 -- Obsolete informational reference (is this intentional?): RFC 7233 (ref. 'HTTP-RANGE') (Obsoleted by RFC 9110) == Outdated reference: A later version (-03) exists of draft-hardie-path-signals-02 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-10 -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. 'TLS12') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 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 March 23, 2018 5 Expires: September 24, 2018 7 Long-term Viability of Protocol Extension Mechanisms 8 draft-thomson-use-it-or-lose-it-01 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 September 24, 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 . . . . . . . . . 2 53 2.1. Good Protocol Design is Not Sufficient . . . . . . . . . 3 54 2.2. Multi-Party Interactions and Middleboxes . . . . . . . . 4 55 3. Retaining Viable Protocol Evolution Mechanisms . . . . . . . 5 56 3.1. Practice Can Ensure Viability . . . . . . . . . . . . . . 5 57 3.2. Dependency is Better . . . . . . . . . . . . . . . . . . 6 58 3.3. Unused Extension Points Become Unusable . . . . . . . . . 7 59 4. Defensive Design Principles for Protocols . . . . . . . . . . 7 60 4.1. Active Use . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Grease . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. Cryptography . . . . . . . . . . . . . . . . . . . . . . 8 63 4.4. Visibility of Faults . . . . . . . . . . . . . . . . . . 9 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Informative References . . . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 69 1. Introduction 71 A successful protocol [SUCCESS] will change in ways that allow it to 72 continue to fulfill the needs of its users. New use cases, 73 conditions and constraints on the deployment of a protocol can render 74 a protocol that does not change obsolete. 76 Usage patterns and requirements for a protocol shift over time. 77 Protocols can react to these shifts in one of three ways: adjust 78 usage patterns within the constraints of the protocol, extend the 79 protocol, and replace the protocol. These reactions are 80 progressively more disruptive, but are also dictated by the nature of 81 the change in requirements over longer periods. 83 Experience with Internet-scale protocol deployment shows that 84 changing protocols is not uniformly successful. [TRANSITIONS] 85 examines the problem more broadly. 87 This document examines the specific conditions that determine whether 88 protocol maintainers have the ability to design and deploy new or 89 modified protocols. Section 4 outlines several strategies that might 90 aid in ensuring that protocol changes remain possible over time. 92 2. Implementations of Protocols are Imperfect 94 A change to a protocol can be made extremely difficult to deploy if 95 there are bugs in implementations with which the new deployment needs 96 to interoperate. Bugs in the handling of new codepoints or 97 extensions can mean that instead of handling the mechanism as 98 designed, endpoints react poorly. This can manifest as abrupt 99 termination of sessions, errors, crashes, or disappearances of 100 endpoints and timeouts. 102 Interoperability with other implementations is usually highly valued, 103 so deploying mechanisms that trigger adverse reactions like these can 104 be untenable. Where interoperability is a competitive advantage, 105 this is true even if the negative reactions happen infrequently or 106 only under relatively rare conditions. 108 Deploying a change to a protocol could require fixing a substantial 109 proportion of the bugs that the change exposes. This can involve a 110 difficult process that includes identifying the cause of these 111 errors, finding the responsible implementation, coordinating a bug 112 fix and release plan, contacting the operator of affected services, 113 and waiting for the fix to be deployed to those services. 115 Given the effort involved in fixing these problems, the existence of 116 these sorts of bugs can outright prevent the deployment of some types 117 of protocol changes. It could even be necessary to come up with a 118 new protocol design that uses a different method to achieve the same 119 result. 121 2.1. Good Protocol Design is Not Sufficient 123 It is often argued that the design of a protocol extension point or 124 version negotiation capability is critical to the freedom that it 125 ultimately offers. 127 RFC 6709 [EXTENSIBILITY] contains a great deal of well-considered 128 advice on designing for extension. It includes the following advice: 130 This means that, to be useful, a protocol version- negotiation 131 mechanism should be simple enough that it can reasonably be 132 assumed that all the implementers of the first protocol version at 133 least managed to implement the version-negotiation mechanism 134 correctly. 136 This has proven to be insufficient in practice. Many protocols have 137 evidence of imperfect implementation of these critical mechanisms. 138 Mechanisms that aren't used are the ones that fail most often. The 139 same paragraph from RFC 6709 acknowledges the existence of this 140 problem, but does not offer any remedy: 142 The nature of protocol version-negotiation mechanisms is that, by 143 definition, they don't get widespread real-world testing until 144 _after_ the base protocol has been deployed for a while, and its 145 deficiencies have become evident. 147 Transport Layer Security (TLS) [TLS12] provides examples of where a 148 design that is objectively sound fails when incorrectly implemented. 149 TLS provides examples of failures in protocol version negotiation and 150 extensibility. 152 Version negotiation in TLS 1.2 and earlier uses the "Highest mutually 153 supported version (HMSV)" scheme exactly as it is described in 154 [EXTENSIBILITY]. However, clients are unable to advertise a new 155 version without causing a non-trivial proportions of sessions to fail 156 due to bugs in server and middlebox implementations. 158 Intolerance to new TLS versions is so severe [INTOLERANCE] that TLS 159 1.3 [TLS13] has abandoned HMSV version negotiation for a new 160 mechanism. 162 The server name indication (SNI) [TLS-EXT] in TLS is another 163 excellent example of the failure of a well-designed extensibility 164 point. SNI uses the same technique for extension that is used with 165 considerable success in other parts of the TLS protocol. The 166 original design of SNI includes the ability to include multiple names 167 of different types. 169 What is telling in this case is that SNI was defined with just one 170 type of name: a domain name. No other type has ever been 171 standardized, though several have been proposed. Despite an 172 otherwise exemplary design, SNI is so inconsistently implemented that 173 any hope for using the extension point it defines has been abandoned 174 [SNI]. 176 2.2. Multi-Party Interactions and Middleboxes 178 Even the most superficially simple protocols can often involve more 179 actors than is immediately apparent. A two-party protocol has two 180 ends, but even at the endpoints of an interaction, protocol elements 181 can be passed on to other entities in ways that can affect protocol 182 operation. 184 One of the key challenges in deploying new features in a protocol is 185 ensuring compatibility with all actors that could influence the 186 outcome. 188 Protocols that deploy without active measures against intermediation 189 can accrue middleboxes that depend on certain aspects of the protocol 190 [PATH-SIGNALS]. In particular, one of the consequences of an 191 unencrypted protocol is that any element on path can interact with 192 the protocol. For example, HTTP was specifically designed with 193 intermediation in mind, transparent proxies [HTTP] are not only 194 possible but sometimes advantageous, despite some significant 195 downsides. Consequently, transparent proxies for cleartext HTTP are 196 commonplace. 198 Middleboxes are also protocol participants, to the degree that they 199 are able to observe and act in ways that affect the protocol. The 200 degree to which a middlebox participates varies from the basic 201 functions that a router performs to full participation. For example, 202 a SIP back-to-back user agent (B2BUA) [B2BUA] can be very deeply 203 involved in the SIP protocol. 205 By increasing the number of different actors involved in any single 206 protocol exchange, the number of potential implementation bugs that a 207 deployment needs to contend with also increases. In particular, 208 incompatible changes to a protocol that might be negotiated between 209 endpoints in ignorance of the presence of a middlebox can result in a 210 middlebox acting badly. 212 Thus, middleboxes can increase the difficulty of deploying changes to 213 a protocol considerably. 215 3. Retaining Viable Protocol Evolution Mechanisms 217 The design of a protocol for extensibility and eventual replacement 218 [EXTENSIBILITY] does not guarantee the ability to exercise those 219 options. Only active use of those mechanisms can ensure that they 220 remain available for new uses. 222 3.1. Practice Can Ensure Viability 224 The fact that the freedom to change depends on practice is evident in 225 protocols that are known to have viable version negotiation or 226 extension points. The definition of mechanisms alone is 227 insufficient; it's the active use of those mechanisms that determines 228 the existence of freedom. 230 For example, header fields in email [SMTP], HTTP [HTTP] and SIP [SIP] 231 all derive from the same basic design. There is no evidence of 232 significant barriers to deploying header fields with new names and 233 semantics in email and HTTP, though the widespread deployment of SIP 234 B2BUAs means that new SIP header fields can be more difficult. 236 In another example, the attribute-value pairs (AVPs) in Diameter 237 [DIAMETER] are fundamental to the design of the protocol. The 238 definition of new uses of Diameter regularly exercise the ability to 239 add new AVPs and do so with no fear that the new feature might not be 240 successfully deployed. 242 These examples show extension points that are heavily used also being 243 relatively unaffected by deployment issues preventing addition of new 244 values for new use cases. 246 These examples also confirm the case that good design is not a 247 prerequisite for success. On the contrary, success is often despite 248 shortcomings in the design. For instance, the shortcomings of HTTP 249 header fields are significant enough that there are ongoing efforts 250 to improve the syntax [HTTP-HEADERS]. 252 Only using a protocol capability is able to ensure availability of 253 that capability. Protocols that fail to use a mechanism, or a 254 protocol that only rarely uses a mechanism, suffer an inability to 255 rely on that mechanism. 257 3.2. Dependency is Better 259 The best way to guarantee that a protocol mechanism is used is to 260 make it critical to an endpoint participating in that protocol. This 261 means that implementations rely on both the existence of the protocol 262 mechanism and its use. 264 For example, the message format in SMTP relies on header fields for 265 most of its functions, including the most basic functions. A 266 deployment of SMTP cannot avoid including an implementation of header 267 field handling. In addition to this, the regularity with which new 268 header fields are defined and used ensures that deployments 269 frequently encounter header fields that it does not understand. An 270 SMTP implementation therefore needs to be able to both process header 271 fields that it understands and ignore those that it does not. 273 In this way, implementing the extensibility mechanism is not merely 274 mandated by the specification, it is crucial to the functioning of a 275 protocol deployment. Should an implementation fail to correctly 276 implement the mechanism, that failure would quickly become apparent. 278 Caution is advised to avoid assuming that building a dependency on an 279 extension mechanism is sufficient to ensure availability of that 280 mechanism in the long term. If the set of possible uses is narrowly 281 constrained and deployments do not change over time, implementations 282 might not see new variations or assume a narrower interpretation of 283 what is possible. Those implementations might still exhibit errors 284 when presented with a new variation. 286 3.3. Unused Extension Points Become Unusable 288 In contrast, there are many examples of extension points in protocols 289 that have been either completely unused, or their use was so 290 infrequent that they could no longer be relied upon to function 291 correctly. 293 HTTP has a number of very effective extension points in addition to 294 the aforementioned header fields. It also has some examples of 295 extension point that are so rarely used that it is possible that they 296 are not at all usable. Extension points in HTTP that might be unwise 297 to use include the extension point on each chunk in the chunked 298 transfer coding [HTTP], the ability to use transfer codings other 299 than the chunked coding, and the range unit in a range request 300 [HTTP-RANGE]. 302 4. Defensive Design Principles for Protocols 304 There are several potential approaches that can provide some measure 305 of protection against a protocol deployment becoming resistant to 306 change. 308 4.1. Active Use 310 As discussed in Section 3, the most effective defense against misuse 311 of protocol extension points is active use. 313 4.2. Grease 315 "Grease" [GREASE] identifies lack of use as an issue (protocol 316 mechanisms "rusting" shut) and proposes a system of use that 317 exercises extension points by using dummy values. 319 The primary feature of the grease design is aimed at the style of 320 negotiation most used in TLS, where the client offers a set of 321 options and the server chooses the one that it most prefers from 322 those that it supports. A client that uses grease randomly offers 323 options (usually just one) from a set of reserved values. These 324 values are guaranteed to never be assigned real meaning, so the 325 server will never have cause to genuinely select one of these values. 327 The principle that grease operates on is that an implementation that 328 is regularly exposed to unknown values is not likely to become 329 intolerant of new values when they appear. This depends largely on 330 the assumption that the difficulty of implementing the protocol 331 mechanism correctly is not significantly more effort than 332 implementing code to specifically filter out the randomized grease 333 values. 335 To avoid simple techniques for filtering greasing codepoints, grease 336 values are not reserved from a single contiguous block of code 337 points, but are distributed evenly across the entire space of code 338 points. Reserving a randomly selected set of code points has a 339 greater chance of avoiding this problem, though it might be more 340 difficult to specify and implement, especially over larger code point 341 spaces. 343 Without reserved greasing codepoints, an implementation can use code 344 points from spaces used for private or experimental use if such a 345 range exists. In addition to the risk of triggering participation in 346 an unwanted experiment, this can be less effective. Incorrect 347 implementations might still be able to correctly identify these code 348 points and ignore them. 350 Grease is deployed with the intent of quickly detecting errors in 351 implementing the mechanisms it safeguards. 353 This form of defensive design has some limitations. It does not 354 necessarily create the need for an implementation to rely on the 355 mechanism it safeguards; that is determined by the underlying 356 protocol itself. More critically, it does not easily translate to 357 other forms of extension point. For instance, HMSV negotiation 358 cannot be greased in this fashion. Other techniques might be 359 necessary for protocols that don't rely on the particular style of 360 exchange that is predominant in TLS. 362 4.3. Cryptography 364 Cryptography can be used to reduce the number of entities that can 365 participate in a protocol. Using tools like TLS ensures that only 366 authorized participants are able to influence whether a new protocol 367 feature is used. 369 Data that is exchanged under encryption cannot be seen by 370 middleboxes, excluding them from participating in that part of the 371 protocol. Similarly, data that is exchanged with integrity 372 protection cannot be modified without being detected and discarded. 374 The QUIC protocol [QUIC] adopts both encryption and integrity 375 protection. Encryption is used to carefully control what information 376 is exposed to middleboxes. QUIC also uses integrity protection over 377 all the data it exchanges to prevent modification. 379 4.4. Visibility of Faults 381 Feedback is critical to the success of the grease technique (see 382 Section 4.2). The system only works if an protocol deployment has a 383 means of detecting and analyzing errors. Ignoring errors could allow 384 those errors to become entrenched. This process can be automated, 385 but when operating at scale it might be difficult or impossible to 386 collect details of specific errors. 388 Feedback on errors is more important during the development and early 389 deployment of a change. Disabling automatic error recovery methods 390 during development improves visibility of errors. 392 Automated feedback systems are important for automated systems, or 393 where error recovery is also automated. For instance, connection 394 failures with HTTP alternative services [ALT-SVC] are not permitted 395 to affect the outcome of transactions. An automated feedback system 396 for capturing failures in alternative services is therefore necessary 397 for failures to be detected. 399 5. Security Considerations 401 The ability to design, implement, and deploy new protocol mechanisms 402 can be critical to security. In particular, it is important to be 403 able to replace cryptographic algorithms over time [AGILITY]. 405 6. IANA Considerations 407 This document makes no request of IANA. 409 7. Informative References 411 [AGILITY] Housley, R., "Guidelines for Cryptographic Algorithm 412 Agility and Selecting Mandatory-to-Implement Algorithms", 413 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 414 . 416 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP 417 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 418 April 2016, . 420 [B2BUA] Kaplan, H. and V. Pascual, "A Taxonomy of Session 421 Initiation Protocol (SIP) Back-to-Back User Agents", 422 RFC 7092, DOI 10.17487/RFC7092, December 2013, 423 . 425 [DIAMETER] 426 Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 427 Ed., "Diameter Base Protocol", RFC 6733, 428 DOI 10.17487/RFC6733, October 2012, 429 . 431 [EXTENSIBILITY] 432 Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design 433 Considerations for Protocol Extensions", RFC 6709, 434 DOI 10.17487/RFC6709, September 2012, 435 . 437 [GREASE] Benjamin, D., "Applying GREASE to TLS Extensibility", 438 draft-ietf-tls-grease-00 (work in progress), January 2017. 440 [HTTP] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 441 Protocol (HTTP/1.1): Message Syntax and Routing", 442 RFC 7230, DOI 10.17487/RFC7230, June 2014, 443 . 445 [HTTP-HEADERS] 446 Nottingham, M. and P. Kamp, "Structured Headers for HTTP", 447 draft-ietf-httpbis-header-structure-04 (work in progress), 448 March 2018. 450 [HTTP-RANGE] 451 Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., 452 "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", 453 RFC 7233, DOI 10.17487/RFC7233, June 2014, 454 . 456 [INTOLERANCE] 457 Kario, H., "Re: [TLS] Thoughts on Version Intolerance", 458 July 2016, . 461 [PATH-SIGNALS] 462 Hardie, T., "Path signals", draft-hardie-path-signals-02 463 (work in progress), November 2017. 465 [QUIC] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 466 and Secure Transport", draft-ietf-quic-transport-10 (work 467 in progress), March 2018. 469 [SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 470 A., Peterson, J., Sparks, R., Handley, M., and E. 471 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 472 DOI 10.17487/RFC3261, June 2002, 473 . 475 [SMTP] Resnick, P., Ed., "Internet Message Format", RFC 5322, 476 DOI 10.17487/RFC5322, October 2008, 477 . 479 [SNI] Langley, A., "Accepting that other SNI name types will 480 never work", March 2016, 481 . 484 [SUCCESS] Thaler, D. and B. Aboba, "What Makes for a Successful 485 Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008, 486 . 488 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) 489 Extensions: Extension Definitions", RFC 6066, 490 DOI 10.17487/RFC6066, January 2011, 491 . 493 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security 494 (TLS) Protocol Version 1.2", RFC 5246, 495 DOI 10.17487/RFC5246, August 2008, 496 . 498 [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol 499 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 500 March 2018. 502 [TRANSITIONS] 503 Thaler, D., Ed., "Planning for Protocol Adoption and 504 Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170, 505 May 2017, . 507 Author's Address 509 Martin Thomson 510 Mozilla 512 Email: martin.thomson@gmail.com