idnits 2.17.00 (12 Aug 2021) /tmp/idnits51624/draft-nottingham-http-grease-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 7, 2020) is 682 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 330 -- Looks like a reference, but probably isn't: '2' on line 332 -- Looks like a reference, but probably isn't: '3' on line 334 -- Looks like a reference, but probably isn't: '4' on line 336 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-cache-08 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-08 == Outdated reference: draft-ietf-httpbis-header-structure has been published as RFC 8941 Summary: 2 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. Nottingham 3 Internet-Draft July 7, 2020 4 Intended status: Informational 5 Expires: January 8, 2021 7 Greasing HTTP 8 draft-nottingham-http-grease-00 10 Abstract 12 Like many network protocols, HTTP is vulnerable to ossification of 13 its extensibility points. This draft specifies how they should be 14 exercised ('greased') to assure their continued usability. 16 Note to Readers 18 _RFC EDITOR: please remove this section before publication_ 20 The issues list for this draft can be found at 21 https://github.com/mnot/I-D/labels/http-grease [1]. 23 The most recent (often, unpublished) draft is at 24 https://mnot.github.io/I-D/http-grease/ [2]. 26 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 27 pages/http-grease [3]. 29 See also the draft's current status in the IETF datatracker, at 30 https://datatracker.ietf.org/doc/draft-nottingham-http-grease/ [4]. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 8, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 1.1. What to Grease? . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. How to Grease? . . . . . . . . . . . . . . . . . . . . . 3 69 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 4 70 2. The HTTP Grease Process . . . . . . . . . . . . . . . . . . . 4 71 2.1. Greasing HTTP Request Header Fields . . . . . . . . . . . 5 72 2.2. Greasing HTTP Request Cache Directives . . . . . . . . . 6 73 3. Security Considerations . . . . . . . . . . . . . . . . . . . 6 74 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 4.1. Normative References . . . . . . . . . . . . . . . . . . 7 76 4.2. Informative References . . . . . . . . . . . . . . . . . 7 77 4.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 Appendix A. Bootstrapping the HTTP Grease Process . . . . . . . 8 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 Like many network protocols, HTTP is vulnerable to ossification of 84 its extensibility points. Those that are rarely exercised risk 85 'rusting shut' because recipients assume that they will not be used. 86 This happens in practice for several reasons, including implementer 87 convenience, performance optimisation, or traffic characterisation. 89 Because extensibility is a primary mechanism for protocol evolution, 90 it is important to keep these extension points flexible. For points 91 that are rarely used, one proven way (pioneered by [RFC8701]) to 92 assure this is through sending 'grease' values - i.e., extension 93 values that are hard to predict and have no effect on correct 94 protocol operation. 96 This document specifies how HTTP's extension points should be 97 greased, to assure their continued usability. It focuses on generic 98 HTTP features; other documents cover versioned extensibility points 99 (e.g., see [I-D.bishop-httpbis-grease]). 101 1.1. What to Grease? 103 HTTP has several extension mechanisms. While keeping all of them 104 available for use is desirable, this document currently targets two 105 specific extensibility points - HTTP request header fields and 106 request cache directives - for a few reasons. 108 Some extension points are not practical to grease. For example, 109 introducing new HTTP methods is important, but greasing them would 110 require sending requests beyond those intended by the user. Beyond 111 the overhead of doing so, failure of those requests is not likely to 112 create an incentive to allow those requests, because that failure is 113 not user visible. 115 Other extension points are already effectively ossified: for example, 116 range units. While it might be possible to introduce a new range 117 unit in the future (with enough effort), there is not much desire to 118 do so in the community at this point, and the risk of greasing it 119 causing too many failures is high. 121 Greasing aspects of HTTP responses (such as header fields or cache 122 control directives) is not addressed in this document because current 123 Web traffic already effectively greases them. For example, the 124 breadth of unrecognised headers sent from HTTP servers effectively 125 keeps response header fields greased; likewise with response cache- 126 control directives. 128 Future revisions might address other extensibility points (including 129 those listed above), based upon discussion and feedback. 131 1.2. How to Grease? 133 Greasing has the goal of keeping protocol extension points flexible - 134 that is, it should remain possible to introduce new values with 135 negligible risk of interoperability problems. By necessity, this is 136 not absolute; an implementation determined to control input values 137 can anticipate grease values and allow them, while denying other 138 extensions. 140 As a result, one of the tradeoffs in a greasing mechanism is between 141 making the values difficult to anticipate and the complexity of the 142 mechanism. One that is hard to anticipate typically requires hard- 143 to-predict values generated by an algorithm, with a corresponding 144 prohibition on registration of those values. Even then, a determined 145 implementation could use heuristics to identify and allow grease 146 values, while blocking others. On the other hand, an easily 147 predictable value can be added to an allow list in implementations, 148 while they still block unknown values. 150 This document's initial goal is to make it possible to deploy new 151 standards-defined values with a suitable notice period, rather than 152 to allow any implementation to introduce new values at any time. To 153 meet that goal, a 'HTTP grease process' is defined, whereby grease 154 values are periodically announced and later sent by implementations, 155 so that receiving implementations have enough time to assure 156 interoperability. 158 1.3. Notational Conventions 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 162 "OPTIONAL" in this document are to be interpreted as described in BCP 163 14 [RFC2119] [RFC8174] when, and only when, they appear in all 164 capitals, as shown here. 166 2. The HTTP Grease Process 168 There are a few parties involved in the greasing of an HTTP 169 extensibility point. They are: 171 o Grease senders - implementers and operators of HTTP deployments 172 that send grease extensions 174 o Grease recipients - implementers and operators of HTTP deployments 175 that receive grease extensions 177 o The grease coordinator - a person appointed to oversee the HTTP 178 grease process 180 To aid communication between these parties, a mailing list (TBD) has 181 been created for announcements and discussion. 183 The grease coordinator is appointed by the ART Area Director(s), in 184 consultation with the HTTP Working Group chair(s). 186 On a periodic basis (to be determined by the grease coordinator in 187 consultation with grease senders and grease recipients), the grease 188 coordinator will announce a new grease value for the extension points 189 covered by this process. Where possible, these values will be 190 provisionally registered with IANA, with the note 'grease value' and 191 a reference to this specification. 193 Such announcements MUST contain the details of the grease value (see 194 individual requirements below), and a date on which grease senders 195 SHOULD start sending that value. 197 Grease senders SHOULD send the grease value on a sizeable fraction of 198 traffic (e.g., 1/8th); too small a proportion might be ignored. 200 Grease senders MAY selectively send grease values. For example, a 201 Web browser might only send grease on navigation requests, to assure 202 that any interoperability problems are clearly visible. 204 Grease senders SHOULD NOT send grease values when the request method 205 is non-idempotent or unsafe. 207 If grease senders or recipients experience widespread 208 interoperability problems as the result of deployment of a grease 209 value, they SHOULD report this to the grease coordinator, who MAY 210 declare that the grease value can be withdrawn by grease senders. 211 Grease senders SHOULD NOT act unilaterally in such cases. 213 Once a new grease value has been deployed, old grease values SHOULD 214 be withdrawn by grease senders. 216 2.1. Greasing HTTP Request Header Fields 218 Grease values for HTTP request header fields consist of a field name 219 and a field value. 221 Grease field names SHOULD be hard to predict; e.g., they SHOULD NOT 222 have any identifying prefix, suffix, or pattern. However, they MUST 223 NOT be likely to conflict with unregistered or future field names, 224 and the grease coordinator MUST avoid potentially offensive or 225 confusing terms. They also MUST conform to the syntactic 226 requirements for field names in HTTP ([I-D.ietf-httpbis-semantics], 227 Section 4.3). 229 This can be achieved in different ways (which SHOULD vary from time 230 to time), for example: 232 o Combine two or three dictionary words or proper nouns with a 233 hyphen (e.g., 'Skateboard-Clancy', 'Murray-Fortnight-Scout') 235 o Append digits to a dictionary word (e.g., 'Turnstile23') 237 o Generate a string using a hash or similar function (e.g., 238 'dd722785c01b') 240 Grease field values can be statically specified in the grease 241 announcement, specified to be of a certain type (e.g., using 242 [I-D.ietf-httpbis-header-structure] types), or left to the discretion 243 of the grease sender. 245 2.2. Greasing HTTP Request Cache Directives 247 Grease values for HTTP request cache directives consist of a 248 directive name and an optional directive value. 250 Grease directive names SHOULD be hard to predict; e.g., they SHOULD 251 NOT have any identifying prefix, suffix, or pattern. However, they 252 MUST NOT be likely to conflict with unregistered or future directive 253 names, and the grease coordinator MUST avoid potentially offensive or 254 confusing terms. They also MUST conform to the syntactic 255 requirements for cache directive names in HTTP 256 ([I-D.ietf-httpbis-cache], Section 5.2). 258 This can be achieved in different ways (which SHOULD vary from time 259 to time), for example: 261 o Select a single dictionary word or proper noun (e.g., 'fanciful', 262 'imagine') 264 o Combine two dictionary words or proper nouns with a hyphen (e.g., 265 'skateboard-clancy') 267 o Append digits to a dictionary word (e.g., 'turnstile23') 269 o Generate a string using a hash or similar function (e.g., 270 'dd722785c01b') 272 Grease field values can be omitted (so there is no '=value'), 273 statically specified in the grease announcement, specified to be of a 274 certain type (e.g., an integer, a quoted string), or left to the 275 discretion of the grease sender. 277 3. Security Considerations 279 Some HTTP extensibility points are becoming (or have become) ossified 280 because of security considerations; receiving implementations believe 281 that it is more secure to reject unknown values, or they are able to 282 identify undesirable peers through their use of extensions. 284 This document does not directly address these concerns, nor does it 285 directly disallow such behaviour. Instead, it aims to encourage the 286 ability to accommodate new extensions more quickly than is now 287 currently possible. 289 4. References 291 4.1. Normative References 293 [I-D.ietf-httpbis-cache] 294 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 295 Caching", draft-ietf-httpbis-cache-08 (work in progress), 296 May 2020. 298 [I-D.ietf-httpbis-semantics] 299 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 300 Semantics", draft-ietf-httpbis-semantics-08 (work in 301 progress), May 2020. 303 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 304 Requirement Levels", BCP 14, RFC 2119, 305 DOI 10.17487/RFC2119, March 1997, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 4.2. Informative References 314 [I-D.bishop-httpbis-grease] 315 Bishop, M., "GREASE for HTTP/2", draft-bishop-httpbis- 316 grease-01 (work in progress), June 2020. 318 [I-D.ietf-httpbis-header-structure] 319 Nottingham, M. and P. Kamp, "Structured Field Values for 320 HTTP", draft-ietf-httpbis-header-structure-19 (work in 321 progress), June 2020. 323 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 324 Sustain Extensibility (GREASE) to TLS Extensibility", 325 RFC 8701, DOI 10.17487/RFC8701, January 2020, 326 . 328 4.3. URIs 330 [1] https://github.com/mnot/I-D/labels/http-grease 332 [2] https://mnot.github.io/I-D/http-grease/ 334 [3] https://github.com/mnot/I-D/commits/gh-pages/http-grease 336 [4] https://datatracker.ietf.org/doc/draft-nottingham-http-grease/ 338 Appendix A. Bootstrapping the HTTP Grease Process 340 Because the initial focus of this document is on two request 341 extension points, the relevant grease senders will be HTTP clients - 342 a combination of Web browsers, HTTP client libraries and 343 intermediaries (such as CDNs). The relevant grease recipients will 344 be HTTP servers (both on the origin and in intermediaries). 346 Broadly speaking, HTTP servers accept these extensions, unless they 347 have a Web Application Firewall (WAF) installed. As such, greasing 348 HTTP successfully will require client implementers, WAF vendors, and 349 in some cases WAF deployers to work together. 351 Clients are likely to be risk-averse; if their implementation alone 352 breaks some Web sites, they can face negative consequences (because 353 their users can easily flee to other implementations). Therefore, a 354 successful greasing strategy needs to include most or all major 355 clients, and their actions need to be coordinated. 357 WAF vendors and deployers often do not coordinate behaviour, and may 358 not have prompt update mechanisms. Therefore, a successful greasing 359 strategy needs to attract them to into community engagement (e.g., 360 using the mailing list above) and needs to accommodate their needs; 361 it is likely they will not be able to deploy updates quickly at 362 first, for example. 364 As a result, when greasing begins, it will be necessary to have long 365 lead times between announcement and sending. Likewise, initial 366 grease values are more likely to succeed (building confidence and 367 engagement) if they are static and simple. 369 For example, the first grease value might be completely static, very 370 simple (e.g., "Grease: 1"), and announced several months ahead of 371 time. Subsequent values can grow in complexity, become more dynamic, 372 and arrive with progressively shorter notice, after discussion within 373 the community. 375 Some clients may not be able to deploy new grease values on a regular 376 basis, and so they will need some sort of update or scheduling 377 mechanism to participate. 379 In cases where greasing breaks deployed sites too widely, clients may 380 wish to temporarily stop greasing while the issue is mitigated. This 381 should be coordinated among all clients, rather than done 382 unilaterally. Mitigations like retrying requests without grease can 383 be performed at any time; the point is to gently increase pressure on 384 servers to accept new values, not to break sites unnecessarily. 386 Author's Address 388 Mark Nottingham 390 Email: mnot@mnot.net 391 URI: https://www.mnot.net/