idnits 2.17.1 draft-davidben-http-client-hint-reliability-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 (30 November 2020) is 1242 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-32 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-32 == Outdated reference: A later version (-01) exists of draft-vvv-httpbis-alps-00 ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 3 errors (**), 0 flaws (~~), 4 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 approved) 30 November 2020 5 Intended status: Experimental 6 Expires: 3 June 2021 8 Client Hint Reliability 9 draft-davidben-http-client-hint-reliability-02 11 Abstract 13 This document defines the Critical-CH HTTP response header, and the 14 ACCEPT_CH HTTP/2 and HTTP/3 frames to allow HTTP servers to reliably 15 specify their Client Hint preferences, with minimal performance 16 overhead. 18 Discussion Venues 20 This note is to be removed before publishing as an RFC. 22 Source for this draft and an issue tracker can be found at 23 https://github.com/davidben/http-client-hint-reliability. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 3 June 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 60 3. The Critical-CH Response Header Field . . . . . . . . . . . . 3 61 3.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. The ACCEPT_CH Frame . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. HTTP/2 ACCEPT_CH Frame . . . . . . . . . . . . . . . . . 5 64 4.2. HTTP/3 ACCEPT_CH Frame . . . . . . . . . . . . . . . . . 6 65 4.3. Processing ACCEPT_CH Frames . . . . . . . . . . . . . . . 7 66 4.4. Interaction with Critical-CH . . . . . . . . . . . . . . 8 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 71 7.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 [I-D.ietf-httpbis-client-hints] defines a response header, Accept-CH, 78 for servers to advertise a set of request headers used for proactive 79 content negotiation. This allows user agents to send request headers 80 only when used, improving their performance overhead as well as 81 reducing passive fingerprinting surface. 83 However, on the first HTTP request to a server, the user agent will 84 not have received the Accept-CH header and may not take the server 85 preferences into account. More generally, the server's configuration 86 may have changed since the most recent HTTP request to the server. 87 This document defines a pair of mechanisms to resolve this: 89 1. an HTTP response header, Critical-CH, for the server to instruct 90 the user agent to retry the request 92 2. an alternate delivery mechanism for Accept-CH in HTTP/2 [RFC7540] 93 and HTTP/3 [I-D.ietf-quic-http], which can avoid the performance 94 hit of a retry in most cases 96 2. Conventions and Definitions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 100 "OPTIONAL" in this document are to be interpreted as described in BCP 101 14 [RFC2119] [RFC8174] when, and only when, they appear in all 102 capitals, as shown here. 104 This document uses the Augmented Backus-Naur Form (ABNF) notation of 105 [RFC5234]. 107 This document uses the variable-length integer encoding and frame 108 diagram format from [I-D.ietf-quic-transport]. 110 3. The Critical-CH Response Header Field 112 When a user agent requests a resource based on a missing or outdated 113 Accept-CH value, it may not send a desired request header field. 114 Neither user agent nor server has enough information to reliably and 115 efficiently recover from this situation. The server can observe that 116 the header is missing, but the user agent may not have supported the 117 header, or may have chosen not to send it. Triggering a new request 118 in these cases would risk an infinite loop or an unnecessary round- 119 trip. 121 Conversely, the user agent can observe that a request header appears 122 in the Accept-CH (Section 3.1 of [I-D.ietf-httpbis-client-hints]) and 123 Vary (Section 7.1.4 of [RFC7231]) response header fields. However, 124 retrying based on this information would waste resources if the 125 resource only used the Client Hint as an optional optimization. 127 This document introduces critical Client Hints. These are the Client 128 Hints which meaningfully change the resulting resource. For example, 129 a server may use the Device-Memory Client Hint [DEVICE-MEMORY] to 130 select simple and complex variants of a resource to different user 131 agents. Such a resource should be fetched consistently across page 132 loads to avoid jarring user-visible switches. 134 The server specifies critical Client Hints with the Critical-CH 135 response header field. It is a Structured Header 136 [I-D.ietf-httpbis-header-structure] whose value MUST be an sf-list 137 (Section 3.1 of [I-D.ietf-httpbis-header-structure]) whose members 138 are tokens (Section 3.3.4 of [I-D.ietf-httpbis-header-structure]). 139 Its ABNF is: 141 Critical-CH = sf-list 143 For example: 145 Critical-CH: Sec-CH-Example, Sec-CH-Example-2 147 Each token listed in the Critical-CH header SHOULD additionally be 148 present in the Accept-CH and Vary response headers. 150 When a user agent receives an HTTP response containing a Critical-CH 151 header, it first processes the Accept-CH header as described in 152 Section 3.1 of [I-D.ietf-httpbis-client-hints]. It then performs the 153 following steps: 155 1. If the request did not use a safe method (Section 4.2.1 of 156 [RFC7231]), ignore the Critical-CH header and continue processing 157 the response as usual. 159 2. If the response was already the result of a retry, ignore the 160 Critical-CH header and continue processing the response as usual. 162 3. Determine the Client Hints that would have been sent given the 163 updated Accept-CH value, incorporating the user agent's local 164 policy and user preferences. See also Section 2.1 of 165 [I-D.ietf-httpbis-client-hints]. 167 4. Compare this result to the Client Hints which were sent. If any 168 Client Hint listed in the Critical-CH header was not previously 169 sent and would now have been sent, retry the request with the new 170 preferences. Otherwise, continue processing the response as 171 usual. 173 Note this procedure does not cause the user agent to send Client 174 Hints it would not otherwise send. 176 3.1. Example 178 For example, if the user agent loads https://example.com with no 179 knowledge of the server's Accept-CH preferences, it may send the 180 following response: 182 GET / HTTP/1.1 183 Host: example.com 185 HTTP/1.1 200 OK 186 Content-Type: text/html 187 Accept-CH: Sec-CH-Example, Sec-CH-Example-2 188 Vary: Sec-CH-Example 189 Critical-CH: Sec-CH-Example 191 In this example, the server, across the whole origin, uses both Sec- 192 CH-Example and Sec-CH-Example-2 Client Hints. However, this resource 193 only uses Sec-CH-Example, which it considers critical. 195 The user agent now processes the Accept-CH header and determines it 196 would have sent both headers. Sec-CH-Example is listed in Critical- 197 CH, so the user agent retries the request, and receives a more 198 specific response. 200 GET / HTTP/1.1 201 Host: example.com 202 Sec-CH-Example: 1 203 Sec-CH-Example-2: 2 205 HTTP/1.1 200 OK 206 Content-Type: text/html 207 Accept-CH: Sec-CH-Example, Sec-CH-Example-2 208 Vary: Sec-CH-Example 209 Critical-CH: Sec-CH-Example 211 4. The ACCEPT_CH Frame 213 While Critical-CH header provides reliability, it requires a retry on 214 some requests. This document additionally introduces the ACCEPT_CH 215 HTTP/2 and HTTP/3 frames as an optimization so the server's Client 216 Hint preferences are usually available before the client's first 217 request. 219 HTTP/2 and HTTP/3 servers which request Client Hints SHOULD send an 220 ACCEPT_CH frame as early as possible. Connections using TLS 221 [RFC8446] which negotiate the Application Layer Protocol Settings 222 (ALPS) [I-D.vvv-tls-alps] extension SHOULD include the ACCEPT_CH 223 frame in the ALPS value as described in [I-D.vvv-httpbis-alps]. This 224 ensures the information is available to the user agent when it makes 225 the first request. 227 [[TODO: Alternatively, is it time to revive draft-bishop-httpbis- 228 extended-settings?]] 230 4.1. HTTP/2 ACCEPT_CH Frame 232 The HTTP/2 ACCEPT_CH frame type is TBD (decimal TBD) and contains 233 zero or more entries, each consisting of a pair of length-delimited 234 strings: 236 +-------------------------------+ 237 | Origin-Len (16) | 238 +-------------------------------+-------------------------------+ 239 | Origin ... 240 +-------------------------------+-------------------------------+ 241 | Value-Len (16) | 242 +-------------------------------+-------------------------------+ 243 | Value ... 244 +---------------------------------------------------------------+ 246 The fields are defined as follows: 248 Origin-Len: An unsigned, 16-bit integer indicating the length, in 249 octets, of the Origin field. 251 Origin: A sequence of characters containing the ASCII serialization 252 of an origin (Section 6.2 of [RFC6454]) that the sender is 253 providing an Accept-CH value for. 255 Value-Len: An unsigned, 16-bit integer indicating the length, in 256 octets, of the Value field. 258 Value: A sequence of characters containing the Accept-CH value for 259 the corresponding origin. This value MUST satisfy the Accept-CH 260 ABNF defined in Section 3.1 of [I-D.ietf-httpbis-client-hints]. 262 Clients MUST NOT send ACCEPT_CH frames. Servers which receive an 263 ACCEPT_CH frame MUST respond with a connection error (Section 5.4.1 264 of [RFC7540]) of type PROTOCOL_ERROR. 266 ACCEPT_CH frames always apply to a single connection, never a single 267 stream. The identifier in the ACCEPT_CH frame MUST be zero. The 268 flags field of an ACCEPT_CH field is unused and MUST be zero. If a 269 user agent receives an ACCEPT_CH frame whose stream identifier or 270 flags field is non-zero, it MUST respond with a connection error of 271 type PROTOCOL_ERROR. 273 4.2. HTTP/3 ACCEPT_CH Frame 275 The HTTP/3 ACCEPT_CH frame type is TBD (decimal TBD) and contains 276 zero or more entries, each containing an origin and a corresponding 277 Accept-CH value. 279 HTTP/3 ACCEPT_CH Entry { 280 Origin Length (i), 281 Origin (..) 282 Value Length (i), 283 Value (..), 284 } 286 HTTP/3 ACCEPT_CH Frame { 287 Type (i) = TBD, 288 Length (i), 289 HTTP/3 ACCEPT_CH Entry (..) ..., 290 } 292 The fields of each HTTP/3 ACCEPT_CH Entry are defined as follows: 294 Origin Length: A variable-length integer containing the length, in 295 bytes, of the Origin field. 297 Origin: A sequence of characters containing the ASCII serialization 298 of an origin (Section 6.2 of [RFC6454]) that the sender is 299 providing an Accept-CH value for. 301 Value Length: A variable-length integer containing the length, in 302 bytes, of the Value field. 304 Value: A sequence of characters containing the Accept-CH value for 305 the corresponding origin. This value MUST satisfy the Accept-CH 306 ABNF defined in Section 3.1 of [I-D.ietf-httpbis-client-hints]. 308 Clients MUST NOT send ACCEPT_CH frames. Servers which receive an 309 ACCEPT_CH frame MUST respond with a connection error (Section 8 of 310 [I-D.ietf-quic-http]) of type H3_FRAME_UNEXPECTED. 312 ACCEPT_CH frames may only be sent on the control stream. Clients 313 which receive an ACCEPT_CH frame on any other stream MUST respond 314 with a connection error of type H3_FRAME_UNEXPECTED. 316 4.3. Processing ACCEPT_CH Frames 318 The user agent remembers the most recently received ACCEPT_CH frame 319 for each HTTP/2 or HTTP/3 connection. When it receives a new 320 ACCEPT_CH frame, either in application data or ALPS, it overwrites 321 this value. As this is an optimization, the user agent MAY bound the 322 size and ignore or forget entries to reduce resource usage. 324 When the user agent makes an HTTP request to a particular origin over 325 an HTTP/2 or HTTP/3 connection, it looks up the origin in the 326 remembered ACCEPT_CH, if any. If it finds a match, it determines 327 additional Client Hints to send, incorporating its local policy and 328 user preferences. See Section 2.1 of 329 [I-D.ietf-httpbis-client-hints]. 331 If there are additional Client Hints, the user agent restarts the 332 request with updated headers. The connection has already been 333 established, so this restart does not incur any additional network 334 latency. Note it may result in a different secondary HTTP cache key 335 (see Section 4.1 of [RFC7234]) and select a different cached 336 response. If the new cached response does not need revalidation, it 337 may not use the connection at all. 339 User agents MUST NOT process Client Hint preferences in ACCEPT_CH 340 frames corresponding to origins for which the connection is not 341 authoritative. Note the procedure above implicitly satisfies this by 342 deferring processing to after the connection has been chosen for a 343 corresponding request. Unauthoritative origins and other unmatched 344 entries are ignored. 346 [[TODO: Some variations on this behavior we could choose instead: 348 * Do new ACCEPT_CH frames override the whole set or implement some 349 kind of update? Overriding the whole set seems simplest and most 350 consistent with an EXTENDED_SETTINGS variant. 352 * Should the user agent reject the ACCEPT_CH frame if there are 353 unexpected origins in there? Deferring avoids needing to worry 354 about this, and ignoring the unused ones may interact better with 355 secondary certs. 357 * Should ACCEPT_CH frames be deferred or just written to the cache 358 when received? Deferred simplifies reasoning about bad origins, 359 predictive connections, etc., but means interactions between 360 ACCEPT_CH and Accept-CH are more complex (see below). 362 * How should ACCEPT_CH and Accept-CH interact? The document 363 currently proposes unioning them, which is easy. Accept-CH first 364 would work, but unnecessarily ignore newer connection-level 365 ACCEPT_CHs. ACCEPT_CH would not; a stale connection-level 366 preference would get stuck. Whichever is received earlier would 367 also work, but requires tracking timestamps if deferred (see 368 above).]] 370 4.4. Interaction with Critical-CH 372 The ACCEPT_CH frame avoids a round-trip, so relying on it over 373 Critical-CH would be preferable. However, this is not always 374 possible: 376 * The server may be running older software without support for 377 ACCEPT_CH or ALPS. 379 * The server's Accept-CH preferences may change while existing 380 connections are open. Those connections will have outdated 381 ACCEPT_CH frames. While the server could send a new frame, it may 382 not arrive in time for the next request. Moreover, if the HTTP 383 serving frontend is an intermediary like a CDN, it may not be 384 proactively notified of origin server changes. 386 * HTTP/2 and HTTP/3 allow connection reuse across multiple origins 387 (Section 9.1.1 of [RFC7540] and Section 3.4 of 388 [I-D.ietf-quic-http]). Some origins may not be listed in the 389 ACCEPT_CH frame, particularly if the server used a wildcard X.509 390 certificate. 392 Thus this document defines both mechanisms. Critical-CH provides 393 reliable Client Hint delivery, while the ACCEPT_CH frame avoids the 394 retry in most cases. 396 5. Security Considerations 398 Request header fields may expose sensitive information about the 399 user's environment. Section 4.1 of [I-D.ietf-httpbis-client-hints] 400 discusses some of these considerations. The document augments the 401 capabilities of Client Hints, but does not change these 402 considerations. The procedure described in Section 3 does not result 403 in the user agent sending request headers it otherwise would not 404 have. 406 The ACCEPT_CH frame does introduce a new way for HTTP/2 or HTTP/3 407 connections to make assertions about origins they are not 408 authoritative for, but the procedure in Section 4.3 defers processing 409 until after the user agent has decided to use the connection for a 410 particular request (Section 9.1.1 of [RFC7540] and Section 3.4 of 411 [I-D.ietf-quic-http]). The user agent will thus only use information 412 from an ACCEPT_CH frame if it considers the connection authoritative 413 for the origin. 415 6. IANA Considerations 417 This specification adds an entry to the "HTTP/2 Frame Type" registry 418 [RFC7540] with the following parameters: 420 * Frame Type: ACCEPT_CH 422 * Code: TBD 423 * Allowed in ALPS: Yes 425 * Reference: [[this document]] 427 This specification adds an entry to the "HTTP/3 Frame Type" registry 428 [I-D.ietf-quic-http] with the following parameters: 430 * Frame Type: ACCEPT_CH 432 * Code: TBD 434 * Allowed in ALPS: Yes 436 * Reference: [[this document]] 438 [[TODO: As of writing, the Frame Type registries do not include 439 Allowed in ALPS columns, but [I-D.vvv-httpbis-alps] adds them. This 440 document should be updated as that design evolves.]] 442 7. References 444 7.1. Normative References 446 [I-D.ietf-httpbis-client-hints] 447 Grigorik, I. and Y. Weiss, "HTTP Client Hints", Work in 448 Progress, Internet-Draft, draft-ietf-httpbis-client-hints- 449 15, 3 July 2020, . 452 [I-D.ietf-httpbis-header-structure] 453 Nottingham, M. and P. Kamp, "Structured Field Values for 454 HTTP", Work in Progress, Internet-Draft, draft-ietf- 455 httpbis-header-structure-19, 3 June 2020, 456 . 459 [I-D.ietf-quic-http] 460 Bishop, M., "Hypertext Transfer Protocol Version 3 461 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 462 quic-http-32, 20 October 2020, . 465 [I-D.ietf-quic-transport] 466 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 467 and Secure Transport", Work in Progress, Internet-Draft, 468 draft-ietf-quic-transport-32, 20 October 2020, 469 . 472 [I-D.vvv-httpbis-alps] 473 Vasiliev, V., "Using TLS Application-Layer Protocol 474 Settings (ALPS) in HTTP", Work in Progress, Internet- 475 Draft, draft-vvv-httpbis-alps-00, 6 July 2020, 476 . 479 [I-D.vvv-tls-alps] 480 Benjamin, D. and V. Vasiliev, "TLS Application-Layer 481 Protocol Settings Extension", Work in Progress, Internet- 482 Draft, draft-vvv-tls-alps-01, 21 September 2020, 483 . 486 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 487 Requirement Levels", BCP 14, RFC 2119, 488 DOI 10.17487/RFC2119, March 1997, 489 . 491 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 492 Specifications: ABNF", STD 68, RFC 5234, 493 DOI 10.17487/RFC5234, January 2008, 494 . 496 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 497 DOI 10.17487/RFC6454, December 2011, 498 . 500 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 501 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 502 DOI 10.17487/RFC7231, June 2014, 503 . 505 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 506 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 507 RFC 7234, DOI 10.17487/RFC7234, June 2014, 508 . 510 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 511 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 512 DOI 10.17487/RFC7540, May 2015, 513 . 515 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 516 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 517 May 2017, . 519 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 520 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 521 . 523 7.2. Informative References 525 [DEVICE-MEMORY] 526 Panicker, S., "Device Memory", n.d., 527 . 529 Acknowledgments 531 This document has benefited from contributions and suggestions from 532 Ilya Grigorik, Nick Harper, Matt Menke, Aaron Tagliaboschi, Victor 533 Vasiliev, Yoav Weiss, and others. 535 Author's Address 537 David Benjamin 538 Google LLC 540 Email: davidben@google.com