idnits 2.17.1 draft-davidben-http-client-hint-reliability-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 : ---------------------------------------------------------------------------- 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 (July 13, 2020) is 1383 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-vvv-httpbis-alps-00 == Outdated reference: A later version (-01) exists of draft-vvv-tls-alps-00 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP D. Benjamin 3 Internet-Draft Google LLC 4 Updates: ietf-httpbis-client-hints (if July 13, 2020 5 approved) 6 Intended status: Experimental 7 Expires: January 14, 2021 9 Client Hint Reliability 10 draft-davidben-http-client-hint-reliability-00 12 Abstract 14 This document defines the Critical-CH HTTP response header, and the 15 ACCEPT_CH HTTP/2 frame to allow HTTP servers to reliably specify 16 their Client Hint preferences, with minimal performance overhead. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on January 14, 2021. 35 Copyright Notice 37 Copyright (c) 2020 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 54 3. The Critical-CH Response Header Field . . . . . . . . . . . . 3 55 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. The ACCEPT_CH HTTP/2 Frame . . . . . . . . . . . . . . . . . 5 57 4.1. Client Behavior . . . . . . . . . . . . . . . . . . . . . 6 58 4.2. Interaction with Critical-CH . . . . . . . . . . . . . . 7 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 7.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 [I-D.ietf-httpbis-client-hints] defines a response header, Accept-CH, 70 for servers to advertise a set of request headers used for proactive 71 content negotiation. This allows clients to send request headers 72 only when used, improving their performance overhead as well as 73 reducing passive fingerprinting surface. 75 However, on the first HTTP request to a server, the client will not 76 have received the Accept-CH header and may not take the server 77 preferences into account. More generally, the server's configuration 78 may have changed since the most recent HTTP request to the server. 79 This document defines a pair of mechanisms to resolve this: 81 1. an HTTP response header, Critical-CH, for the server to instruct 82 the client to retry the request 84 2. an alternate delivery mechanism for Accept-CH in HTTP/2 85 [RFC7540], which can avoid the performance hit of a retry in most 86 cases 88 2. Conventions and Definitions 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 92 "OPTIONAL" in this document are to be interpreted as described in BCP 93 14 [RFC2119] [RFC8174] when, and only when, they appear in all 94 capitals, as shown here. 96 This document uses the Augmented Backus-Naur Form (ABNF) notation of 97 [RFC5234]. 99 3. The Critical-CH Response Header Field 101 When a client requests a resource based on a missing or outdated 102 Accept-CH value, it may not send a desired request header field. 103 Neither client nor server has enough information to reliably and 104 efficiently recover from this situation. The server can observe that 105 the header is missing, but the client may not have supported the 106 header, or may have chosen not to send it. Triggering a new request 107 in these cases would risk an infinite loop or an unnecessary round- 108 trip. 110 Conversely, the client can observe that a request header appears in 111 the Accept-CH (Section 3.1 of [I-D.ietf-httpbis-client-hints]) and 112 Vary (Section 7.1.4 of [RFC7231]) response header fields. However, 113 retrying based on this information would waste resources if the 114 resource only used the Client Hint as an optional optimization. 116 This document introduces critical Client Hints. These are the Client 117 Hints which meaningfully change the resulting resource. For example, 118 a server may use the Device-Memory Client Hint [DEVICE-MEMORY] to 119 select simple and complex variants of a resource to different 120 clients. Such a resource should be fetched consistently across page 121 loads to avoid jarring user-visible switches. 123 The server specifies critical Client Hints with the Critical-CH 124 response header field. It is a Structured Header 125 [I-D.ietf-httpbis-header-structure] whose value MUST be an sf-list 126 (Section 3.1 of [I-D.ietf-httpbis-header-structure]) whose members 127 are tokens (Section 3.3.4 of [I-D.ietf-httpbis-header-structure]). 128 Its ABNF is: 130 Critical-CH = sf-list 132 For example: 134 Critical-CH: Sec-CH-Example, Sec-CH-Example-2 136 Each token listed in the Critical-CH header SHOULD additionally be 137 present in the Accept-CH and Vary response headers. 139 When a user agent receives an HTTP response containing a Critical-CH 140 header, it first processes the Accept-CH header as described in 141 Section 3.1 of [I-D.ietf-httpbis-client-hints]. It then performs the 142 following steps: 144 1. If the request did not use a safe method (Section 4.2.1 of 145 [RFC7231]), ignore the Critical-CH header and continue processing 146 the response as usual. 148 2. If the response was already the result of a retry, ignore the 149 Critical-CH header and continue processing the response as usual. 151 3. Determine the Client Hints that would have been sent given the 152 updated Accept-CH value, incorporating the user agent's local 153 policy and user preferences. See also Section 2.1 of 154 [I-D.ietf-httpbis-client-hints]. 156 4. Compare this result to the Client Hints which were sent. If any 157 Client Hint listed in the Critical-CH header was not previously 158 sent and would now have been sent, retry the request with the new 159 preferences. Otherwise, continue processing the response as 160 usual. 162 Note this procedure does not cause the user agent to send Client 163 Hints it would not otherwise send. 165 3.1. Example 167 For example, if the user agent loads https://example.com with no 168 knowledge of the server's Accept-CH preferences, it may send the 169 following response: 171 GET / HTTP/1.1 172 Host: example.com 174 HTTP/1.1 200 OK 175 Content-Type: text/html 176 Accept-CH: Sec-CH-Example, Sec-CH-Example-2 177 Vary: Sec-CH-Example 178 Critical-CH: Sec-CH-Example 180 In this example, the server, across the whole origin, uses both Sec- 181 CH-Example and Sec-CH-Example-2 Client Hints. However, this resource 182 only uses Sec-CH-Example, which it considers critical. 184 The user agent now processes the Accept-CH header and determines it 185 would have sent both headers. Sec-CH-Example is listed in Critical- 186 CH, so the user agent retries the request, and receives a more 187 specific response. 189 GET / HTTP/1.1 190 Host: example.com 191 Sec-CH-Example: 1 192 Sec-CH-Example-2: 2 194 HTTP/1.1 200 OK 195 Content-Type: text/html 196 Accept-CH: Sec-CH-Example, Sec-CH-Example-2 197 Vary: Sec-CH-Example 198 Critical-CH: Sec-CH-Example 200 4. The ACCEPT_CH HTTP/2 Frame 202 While Critical-CH header provides reliability, it requires a retry on 203 some requests. This document additionally introduces the ACCEPT_CH 204 HTTP/2 frame as an optimization so the server's Client Hint 205 preferences are usually available before the client's first request. 207 [[TODO: Alternatively, is it time to revive draft-bishop-httpbis- 208 extended-settings?]] 210 The ACCEPT_CH frame type is TBD (decimal TBD) and contains one or 211 more entries, each consisting of a pair of length-delimited strings: 213 +-------------------------------+ 214 | Origin-Len (16) | 215 +-------------------------------+-------------------------------+ 216 | Origin ... 217 +-------------------------------+-------------------------------+ 218 | Accept-CH-Len (16) | 219 +-------------------------------+-------------------------------+ 220 | Accept-CH-Value ... 221 +---------------------------------------------------------------+ 223 The fields are defined as follows: 225 Origin-Len: An unsigned, 16-bit integer indicating the length, in 226 octets, of the Origin field. 228 Origin: A sequence of characters containing the ASCII serialization 229 of an origin (Section 6.2 of [RFC6454]) that the sender is 230 providing an Accept-CH value for. 232 Accept-CH-Len: An unsigned, 16-bit integer indicating the length, in 233 octets, of the Accept-CH-Value field. 235 Accept-CH-Value: A sequence of characters containing the Accept-CH 236 value for the corresponding origin. This value MUST satisfy the 237 Accept-CH ABNF defined in Section 3.1 of 238 [I-D.ietf-httpbis-client-hints]. 240 HTTP/2 Servers which request Client Hints SHOULD send an ACCEPT_CH 241 frame as early as possible. Connections using TLS [RFC8446] which 242 negotiate the Application Layer Protocol Settings (ALPS) 243 [I-D.vvv-tls-alps] extension SHOULD include the ACCEPT_CH frame in 244 the ALPS value as described in [I-D.vvv-httpbis-alps]. This ensures 245 the information is available to the client when it makes the first 246 request. 248 Clients MUST NOT send ACCEPT_CH frames. Servers which receive an 249 ACCEPT_CH frame MUST respond with a connection error (Section 5.4.1 250 of [RFC7540]) of type PROTOCOL_ERROR. 252 ACCEPT_CH frames always apply to a single connection, never a single 253 stream. The identifier in the ACCEPT_CH frame MUST be zero. The 254 flags field of an ACCEPT_CH field is unused and MUST be zero. If a 255 client receives an ACCEPT_CH frame whose stream identifier or flags 256 field is non-zero, it MUST respond with a connection error of type 257 PROTOCOL_ERROR. 259 4.1. Client Behavior 261 The client remembers the most recently received ACCEPT_CH frame for 262 each connection. When it receives a new ACCEPT_CH frame, either in 263 application data or ALPS, it overwrites this value. As this is an 264 optimization, the client MAY bound the size and ignore or forget 265 entries to reduce resource usage. 267 When the client makes an HTTP request to a particular origin over an 268 HTTP/2 connection, it looks up the origin in the remembered 269 ACCEPT_CH, if any. If it finds a match, it treats the union of that 270 value and any saved Accept-CH response header as the server's Client 271 Hint preferences. It then proceeds as in Section 2.1 of 272 [I-D.ietf-httpbis-client-hints]. 274 Clients MUST NOT process Client Hint preferences in ACCEPT_CH frames 275 corresponding to origins for which the connection is not 276 authoritative. Note the procedure above implicitly satisfies this by 277 deferring processing to after the connection has been chosen for a 278 corresponding request. Unauthoritative origins and other unmatched 279 entries are ignored. 281 [[TODO: Some variations on this behavior we could choose instead: 283 o Do new ACCEPT_CH frames override the whole set or implement some 284 kind of update? Overriding the whole set seems simplest and most 285 consistent with an EXTENDED_SETTINGS variant. 287 o Should the client reject the ACCEPT_CH frame if there are 288 unexpected origins in there? Deferring avoids needing to worry 289 about this, and ignoring the unused ones may interact better with 290 secondary certs. 292 o Should ACCEPT_CH frames be deferred or just written to the cache 293 when received? Deferred simplifies reasoning about bad origins, 294 predictive connections, etc., but means interactions between 295 ACCEPT_CH and Accept-CH are more complex (see below). 297 o How should ACCEPT_CH and Accept-CH interact? The document 298 currently proposes unioning them, which is easy. Accept-CH first 299 would work, but unnecessarily ignore newer connection-level 300 ACCEPT_CHs. ACCEPT_CH would not; a stale connection-level 301 preference would get stuck. Whichever is received earlier would 302 also work, but requires tracking timestamps if deferred (see 303 above).]] 305 4.2. Interaction with Critical-CH 307 The ACCEPT_CH frame avoids a round-trip, so relying on it over 308 Critical-CH would be preferable. However, this is not always 309 possible: 311 o The server may be running older software without support for 312 ACCEPT_CH or ALPS. 314 o The server's Accept-CH preferences may change while clients have 315 existing connections open. In this case, the connection-level 316 settings may be out of date. While the server could send a new 317 ACCEPT_CH frame, the frame may not arrive in time for the client's 318 next request. Moreover, if the HTTP serving frontend is an 319 intermediary like a CDN, it may not be proactively notified of 320 origin server changes. 322 o HTTP/2 allows connection reuse across multiple origins 323 (Section 9.1.1 of [RFC7540]). Some origins may not be listed in 324 the ACCEPT_CH frame, particularly if the server used a wildcard 325 X.509 certificate. 327 Thus this document defines both mechanisms. Critical-CH provides 328 reliable Client Hint delivery, while the ACCEPT_CH frame avoids the 329 retry in most cases. 331 5. Security Considerations 333 Request header fields may expose sensitive information about the 334 user's environment. Section 4.1 of [I-D.ietf-httpbis-client-hints] 335 discusses some of these considerations. The document augments the 336 capabilities of Client Hints, but does not change these 337 considerations. The procedure described in Section 3 does not result 338 in the user agent sending request headers it otherwise would not 339 have. 341 The ACCEPT_CH frame does introduce a new way for HTTP/2 connections 342 to make assertions about origins they are not authoritative for, but 343 the procedure in Section 4.1 defers processing until after the client 344 has decided to use the connection for a particular request 345 (Section 9.1.1 of [RFC7540]). 347 6. IANA Considerations 349 This specification adds an entry to the "HTTP/2 Frame Type" registry 350 with the following parameters: 352 o Frame Type: ACCEPT_CH 354 o Code: TBD 356 o Allowed in ALPS: Yes 358 o Reference: [[this document]] 360 [[TODO: As of writing, the HTTP/2 Frame Type registry does not 361 include an Allowed in ALPS column. [I-D.vvv-httpbis-alps], as of 362 writing, will add it. This document should be updated as that design 363 evolves.]] 365 7. References 367 7.1. Normative References 369 [I-D.ietf-httpbis-client-hints] 370 Grigorik, I. and Y. Weiss, "HTTP Client Hints", draft- 371 ietf-httpbis-client-hints-15 (work in progress), July 372 2020. 374 [I-D.ietf-httpbis-header-structure] 375 Nottingham, M. and P. Kamp, "Structured Field Values for 376 HTTP", draft-ietf-httpbis-header-structure-19 (work in 377 progress), June 2020. 379 [I-D.vvv-httpbis-alps] 380 Vasiliev, V., "Using TLS Application-Layer Protocol 381 Settings (ALPS) in HTTP", draft-vvv-httpbis-alps-00 (work 382 in progress), July 2020. 384 [I-D.vvv-tls-alps] 385 Vasiliev, V., "TLS Application-Layer Protocol Settings 386 Extension", draft-vvv-tls-alps-00 (work in progress), June 387 2020. 389 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 390 Requirement Levels", BCP 14, RFC 2119, 391 DOI 10.17487/RFC2119, March 1997, 392 . 394 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 395 Specifications: ABNF", STD 68, RFC 5234, 396 DOI 10.17487/RFC5234, January 2008, 397 . 399 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 400 DOI 10.17487/RFC6454, December 2011, 401 . 403 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 404 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 405 DOI 10.17487/RFC7231, June 2014, 406 . 408 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 409 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 410 DOI 10.17487/RFC7540, May 2015, 411 . 413 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 414 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 415 May 2017, . 417 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 418 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 419 . 421 7.2. Informative References 423 [DEVICE-MEMORY] 424 Panicker, S., "Device Memory", n.d., 425 . 427 Acknowledgments 429 This document has benefited from contributions and suggestions from 430 Ilya Grigorik, Nick Harper, Aaron Tagliaboschi, Victor Vasiliev, Yoav 431 Weiss, and others. 433 Author's Address 435 David Benjamin 436 Google LLC 438 Email: davidben@google.com