idnits 2.17.00 (12 Aug 2021) /tmp/idnits33023/draft-nottingham-http-grease-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 : ---------------------------------------------------------------------------- ** 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Greasing clients SHOULD not reuse other clients' grease fields names, unless they coordinate. -- The document date (October 8, 2020) is 583 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 266 -- Looks like a reference, but probably isn't: '2' on line 268 -- Looks like a reference, but probably isn't: '3' on line 270 -- Looks like a reference, but probably isn't: '4' on line 272 == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-semantics-12 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-httpbis-semantics' == Outdated reference: draft-ietf-httpbis-header-structure has been published as RFC 8941 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Nottingham 3 Internet-Draft October 8, 2020 4 Intended status: Best Current Practice 5 Expires: April 11, 2021 7 Greasing HTTP 8 draft-nottingham-http-grease-01 10 Abstract 12 Like many network protocols, HTTP is vulnerable to ossification of 13 its extensibility points. This draft explains why HTTP ossification 14 is a problem and establishes guidelines for exercising those 15 extensions by 'greasing' the protocol to combat it. 17 Note to Readers 19 _RFC EDITOR: please remove this section before publication_ 21 The issues list for this draft can be found at 22 https://github.com/mnot/I-D/labels/http-grease [1]. 24 The most recent (often, unpublished) draft is at 25 https://mnot.github.io/I-D/http-grease/ [2]. 27 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 28 pages/http-grease [3]. 30 See also the draft's current status in the IETF datatracker, at 31 https://datatracker.ietf.org/doc/draft-nottingham-http-grease/ [4]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 11, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 69 2. Ossification and HTTP . . . . . . . . . . . . . . . . . . . . 3 70 2.1. Greasing HTTP Request Header Fields . . . . . . . . . . . 4 71 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 4. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 4.2. Informative References . . . . . . . . . . . . . . . . . 6 75 4.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 78 1. Introduction 80 Like many network protocols, HTTP is vulnerable to ossification of 81 its extensibility points. Ossification happens when a significant 82 number of the systems that generate, transmit, handle, or consume the 83 protocol don't accept a new extension, thereby making it more 84 difficult to deploy extensions. 86 For example, TCP has effectively been ossified by middleboxes that 87 assume that new TCP options will not be deployed; likewise, the 88 Protocol field in IP has been effectively ossified as well, since so 89 many networks will only accept TCP or UDP traffic. 91 Addressing this issue is important; protocol extensibility allows 92 adaptation to new circumstances as well as application to new use 93 cases. Inability to deploy new extensions creates pressure to misuse 94 the protocol - often leading to undesirable side effects - or to use 95 other protocols, reducing the value that the community gets from a 96 shared, standard protocol. 98 While there are a few ways that protocol designers can mitigate 99 ossification, this document focuses on a technique that's well suited 100 to many of the ossification risks in HTTP: 'greasing' extensibility 101 points by exercising them, so that they don't become 'rusted shut.' 103 [RFC8701]) pioneered greasing techniques in IETF protocols; this 104 document explains how they apply to HTTP. It focuses on generic HTTP 105 features; other documents cover versioned extensibility points (e.g., 106 see [I-D.bishop-httpbis-grease]). 108 1.1. Notational Conventions 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 2. Ossification and HTTP 118 As an application protocol, HTTP has several extensibility points. 119 For example, methods, status codes, header and trailer fields, cache 120 directives, range units and content codings are all HTTP extension 121 points. 123 Each extension point defines how unrecognised values should be 124 handled; in most cases, they should be ignored (e.g. header fields, 125 cache directives and range units), while in a few cases they have 126 other handling (e.g., unrecognised methods result in a 405 status 127 code; unrecognised status codes devolve to a more generic x00 status 128 code). 130 Implementations and other components that diverge from these defined 131 behaviours risk ossifying that extensibility point. 133 For example, it is increasingly common for Web Application Firewalls 134 (WAFs), bot detection services and similar components to reject HTTP 135 requests that contain header fields with certain characters or 136 strings, even though syntactically valid, and even though the header 137 fields are not necessarily recognised by the recipient. 139 This behaviour has become prevalent enough to make it difficult for 140 Web browsers and other clients to introduce new request header 141 fields. That difficulty is aggravated by two factors: 143 1. A relatively large number of vendors create these components, but 144 have little coordination between them, leading to wide variances 145 in behaviour, and 147 2. Many of these components' deployments are not updated regularly 148 and reliably, leading to difficulty in addressing ossification 149 issues even when they are identified. 151 To avoid ossification of request header fields, it is Best Current 152 Practice to grease them, as explained below. Other HTTP 153 extensibility points might be added in the future, and it is not to 154 be inferred that greasing other HTTP extensibility points is not good 155 practice. 157 2.1. Greasing HTTP Request Header Fields 159 HTTP clients SHOULD grease request header fields. There are two aims 160 in doing so: 162 1. Preserving the ability to add new request header fields over time 164 2. Preserving the ability to add new request header fields with 165 values containing common syntax 167 Clients can grease a given request at their discretion. For example, 168 a client implementation might add one or more grease request header 169 fields to every request it makes, or it might add one to every third 170 or tenth request. 172 Depending on the deployment model of the client, it might do this in 173 production releases automatically (especially if there are ways that 174 it can modify how grease values are sent with a high degree of 175 control, in case too many errors are encountered), or it might do so 176 only in pre-releases. 178 Grease field names SHOULD be hard to predict; e.g., they SHOULD NOT 179 have any identifying prefix, suffix, or pattern. However, they MUST 180 NOT be likely to conflict with unregistered or future field names, 181 and the grease coordinator MUST avoid potentially offensive or 182 confusing terms. They also MUST conform to the syntactic 183 requirements for field names in HTTP ([I-D.ietf-httpbis-semantics], 184 Section 4.3). 186 This can be achieved in different ways (which SHOULD vary from time 187 to time), for example: 189 o Combine two or three dictionary words or proper nouns with a 190 hyphen (e.g., 'Skateboard-Clancy', 'Murray-Fortnight-Scout') 192 o Append digits to a dictionary word (e.g., 'Turnstile23') 193 o Generate a string using a hash or similar function (e.g., 194 'dd722785c01b') 196 Grease field names are not required to be registered in the IANA HTTP 197 Field Name Registry, unless they are intended to be used over an 198 extended period of time (e.g., more than one year). However, they 199 MAY be registered as Provisional with a reference to this RFC or 200 another explanatory resource, to help interested parties to find out 201 what they are used for. Such registered values SHOULD be removed 202 after the client stops using that field. 204 Greasing clients SHOULD not reuse other clients' grease fields names, 205 unless they coordinate. 207 Grease field values can be fixed strings, or dynamically generated at 208 runtime. It is RECOMMENDED that greasing clients exercise the 209 various types in [I-D.ietf-httpbis-header-structure]. 211 If an error is encountered by a greasing client, it SHOULD NOT re- 212 issue the request without the grease value, since hiding the 213 consequences of the failure doesn't serve the purpose of greasing. 215 Greasing clients SHOULD announce new field names they intend to 216 grease on the http-grease@ietf.org mailing list. 218 3. Security Considerations 220 Some HTTP extensibility points are becoming (or have become) ossified 221 because of security considerations; receiving implementations believe 222 that it is more secure to reject unknown values, or that they can 223 identify undesirable peers through their use of extensions. 225 This document does not directly address these concerns, nor does it 226 directly disallow such behaviour. Instead, it aims to encourage the 227 ability to accommodate new extensions more quickly than is now 228 possible. 230 4. References 232 4.1. Normative References 234 [I-D.ietf-httpbis-semantics] 235 Fielding, R., Nottingham, M., and J. Reschke, "HTTP 236 Semantics", draft-ietf-httpbis-semantics-12 (work in 237 progress), October 2020. 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, 241 DOI 10.17487/RFC2119, March 1997, 242 . 244 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 245 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 246 May 2017, . 248 4.2. Informative References 250 [I-D.bishop-httpbis-grease] 251 Bishop, M., "GREASE for HTTP/2", draft-bishop-httpbis- 252 grease-01 (work in progress), June 2020. 254 [I-D.ietf-httpbis-header-structure] 255 Nottingham, M. and P. Kamp, "Structured Field Values for 256 HTTP", draft-ietf-httpbis-header-structure-19 (work in 257 progress), June 2020. 259 [RFC8701] Benjamin, D., "Applying Generate Random Extensions And 260 Sustain Extensibility (GREASE) to TLS Extensibility", 261 RFC 8701, DOI 10.17487/RFC8701, January 2020, 262 . 264 4.3. URIs 266 [1] https://github.com/mnot/I-D/labels/http-grease 268 [2] https://mnot.github.io/I-D/http-grease/ 270 [3] https://github.com/mnot/I-D/commits/gh-pages/http-grease 272 [4] https://datatracker.ietf.org/doc/draft-nottingham-http-grease/ 274 Author's Address 276 Mark Nottingham 277 made in 278 Prahran, VIC 279 Australia 281 Email: mnot@mnot.net 282 URI: https://www.mnot.net/