idnits 2.17.00 (12 Aug 2021) /tmp/idnits19998/draft-ietf-httpbis-origin-frame-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 == 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: Because ORIGIN can change the set of origins a connection is used for over time, it is possible that a client might have more than one viable connection to an origin open at any time. When this occurs, clients SHOULD not emit new requests on any connection whose Origin Set is a subset of another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. -- The document date (February 13, 2017) is 1922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 2818 -- Obsolete informational reference (is this intentional?): RFC 5988 (Obsoleted by RFC 8288) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP Working Group M. Nottingham 3 Internet-Draft E. Nygren 4 Intended status: Standards Track Akamai 5 Expires: August 17, 2017 February 13, 2017 7 The ORIGIN HTTP/2 Frame 8 draft-ietf-httpbis-origin-frame-02 10 Abstract 12 This document specifies the ORIGIN frame for HTTP/2, to indicate what 13 origins are available on a given connection. 15 Note to Readers 17 Discussion of this draft takes place on the HTTP working group 18 mailing list (ietf-http-wg@w3.org), which is archived at 19 https://lists.w3.org/Archives/Public/ietf-http-wg/ . 21 Working Group information can be found at http://httpwg.github.io/ ; 22 source code and issues list for this draft can be found at 23 https://github.com/httpwg/http-extensions/labels/origin-frame . 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 http://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 August 17, 2017. 42 Copyright Notice 44 Copyright (c) 2017 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 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 61 2. The ORIGIN HTTP/2 Frame . . . . . . . . . . . . . . . . . . . 3 62 2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2.2. Processing ORIGIN Frames . . . . . . . . . . . . . . . . 3 64 2.3. The Origin Set . . . . . . . . . . . . . . . . . . . . . 4 65 2.4. Authority, Push and Coalescing with ORIGIN . . . . . . . 5 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 6 70 5.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Appendix A. Non-Normative Processing Algorithm . . . . . . . . . 7 72 Appendix B. Operational Considerations for Servers . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 HTTP/2 [RFC7540] allows clients to coalesce different origins 78 [RFC6454] onto the same connection when certain conditions are met. 79 However, in certain cases, a connection is is not usable for a 80 coalesced origin, so the 421 (Misdirected Request) status code 81 ([RFC7540], Section 9.1.2) was defined. 83 Using a status code in this manner allows clients to recover from 84 misdirected requests, but at the penalty of adding latency. To 85 address that, this specification defines a new HTTP/2 frame type, 86 "ORIGIN", to allow servers to indicate what origins a connection is 87 usable for. 89 Additionally, experience has shown that HTTP/2's requirement to 90 establish server authority using both DNS and the server's 91 certificate is onerous. This specification relaxes the requirement 92 to check DNS when the ORIGIN frame is in use. Doing so has 93 additional benefits, such as removing the latency associated with 94 some DNS lookups, and improving DNS privacy. 96 1.1. Notational Conventions 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in [RFC2119]. 102 2. The ORIGIN HTTP/2 Frame 104 The ORIGIN HTTP/2 frame ([RFC7540], Section 4) allows a server to 105 indicate what origin(s) [RFC6454] the server would like the client to 106 consider as members of the Origin Set (Section 2.3) for the 107 connection it occurs within. 109 2.1. Syntax 111 The ORIGIN frame type is 0xb (decimal 11). 113 +-------------------------------+-------------------------------+ 114 | Origin-Len (16) | ASCII-Origin? (*) ... 115 +-------------------------------+-------------------------------+ 117 The ORIGIN frame's payload contains the following fields, sets of 118 which may be repeated within the frame to indicate multiple origins: 120 Origin-Len: An unsigned, 16-bit integer indicating the length, in 121 octets, of the ASCII-Origin field. 123 Origin: An optional sequence of characters containing the ASCII 124 serialization of an origin ([RFC6454], Section 6.2) that the 125 sender believes this connection is or could be authoritative for. 127 The ORIGIN frame does not define any flags. However, future updates 128 to this specification MAY define flags. See Section 2.2. 130 2.2. Processing ORIGIN Frames 132 The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints 133 that do not support this frame can safely ignore it upon receipt. 135 When received by an implementing client, it is used to initialise and 136 manipulate the Origin Set (see Section 2.3), thereby changing how the 137 client establishes authority for origin servers (see Section 2.4). 139 The origin frame MUST be sent on stream 0; an ORIGIN frame on any 140 other stream is invalid and MUST be ignored. 142 Likewise, the ORIGIN frame is only valid on connections with the "h2" 143 protocol identifier, or when specifically nominated by the protocol's 144 definition; it MUST be ignored when received on a connection with the 145 "h2c" protocol identifier. 147 This specification does not define any flags for the ORIGIN frame, 148 but future updates might use them to change its semantics. The first 149 four flags (0x1, 0x2, 0x4 and 0x8) are reserved for backwards- 150 incompatible changes, and therefore when any of them are set, the 151 ORIGIN frame containing them MUST be ignored by clients conforming to 152 this specification. The remaining flags are reserved for backwards- 153 compatible changes, and do not affect processing by clients 154 conformant to this specification. 156 The ORIGIN frame describes a property of the connection, and 157 therefore is processed hop-by-hop. An intermediary MUST NOT forward 158 ORIGIN frames. Clients configured to use a proxy MUST ignore any 159 ORIGIN frames received from it. 161 Each ASCII-Origin field in the frame's payload MUST be parsed as an 162 ASCII serialisation of an origin ([RFC6454], Section 6.2). If 163 parsing fails, the field MUST be ignored. 165 See Appendix A for an illustrative algorithm for processing ORIGIN 166 frames. 168 2.3. The Origin Set 170 The set of origins (as per [RFC6454]) that a given connection might 171 be used for is known in this specification as the Origin Set. 173 By default, a connections's Origin Set is uninitialised. When an 174 ORIGIN frame is first received and successfully processed by a 175 client, the connection's Origin Set is defined to contain a single 176 origin, composed from: 178 o Scheme: "https" 180 o Host: the value sent in Server Name Indication ([RFC6066] 181 Section 3), converted to lower case 183 o Port: the remote port of the connection (i.e., the server's port) 185 The contents of that ORIGIN frame (and subsequent ones) allows the 186 server to incrementally add new origins to the Origin Set, as 187 described in Section 2.2. 189 The Origin Set is also affected by the 421 (Misdirected Request) 190 response status code, defined in [RFC7540] Section 9.1.2. Upon 191 receipt of a response with this status code, implementing clients 192 MUST create the ASCII serialisation of the corresponding request's 193 origin (as per [RFC6454], Section 6.2) and remove it from the 194 connection's Origin Set, if present. 196 2.4. Authority, Push and Coalescing with ORIGIN 198 [RFC7540], Section 10.1 uses both DNS and the presented TLS 199 certificate to establish the origin server(s) that a connection is 200 authoritative for, just as HTTP/1.1 does in [RFC7230]. Furthermore, 201 [RFC7540] Section 9.1.1 explicitly allows a connection to be used for 202 more than one origin server, if it is authoritative. This affects 203 what requests can be sent on the connection, both in HEADERS frame by 204 the client and as PUSH_PROMISE frames from the server. 206 Once an Origin Set has been initialised for a connection, clients 207 that implement this specification change these behaviors in the 208 following ways: 210 o Clients MUST NOT consult DNS to establish the connection's 211 authority for new requests. The TLS certificate MUST stil be used 212 to do so, as described in [RFC7540] Section 9.1.1. 214 o Clients sending a new request SHOULD use an existing connection if 215 the request's origin is in that connection's Origin Set, unless 216 there are operational reasons for creating a new connection. 218 o Clients MUST use the Origin Set to determine whether a received 219 PUSH_PROMISE is authoritative, as described in [RFC7540], 220 Section 8.2.2. 222 Note that clients are still required to perform checks on the 223 certificate presented by the server for each origin that a connection 224 is used for; see [RFC7540] Section 9.1.1 for more information. This 225 includes verifying that the host matches a "dNSName" value from the 226 certificate "subjectAltName" field (using the wildcard rules defined 227 in [RFC2818]; see also [RFC5280] Section 4.2.1.6). 229 Because ORIGIN can change the set of origins a connection is used for 230 over time, it is possible that a client might have more than one 231 viable connection to an origin open at any time. When this occurs, 232 clients SHOULD not emit new requests on any connection whose Origin 233 Set is a subset of another connection's Origin Set, and SHOULD close 234 it once all outstanding requests are satisfied. 236 3. IANA Considerations 238 This specification adds an entry to the "HTTP/2 Frame Type" registry. 240 o Frame Type: ORIGIN 242 o Code: 0xb 244 o Specification: [this document] 246 4. Security Considerations 248 Clients that blindly trust the ORIGIN frame's contents will be 249 vulnerable to a large number of attacks. See Section 2.4 for 250 mitigations. 252 Relaxing the requirement to consult DNS when determining authority 253 for an origin means that an attacker who possesses a valid 254 certificate no longer needs to be on-path to redirect traffic to 255 them; instead of modifying DNS, they need only convince the user to 256 visit another Web site, in order to coalesce connections to the 257 target onto their existing connection. 259 5. References 261 5.1. Normative References 263 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 264 Requirement Levels", BCP 14, RFC 2119, 265 DOI 10.17487/RFC2119, March 1997, 266 . 268 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 269 DOI 10.17487/RFC2818, May 2000, 270 . 272 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 273 Housley, R., and W. Polk, "Internet X.509 Public Key 274 Infrastructure Certificate and Certificate Revocation List 275 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 276 . 278 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 279 Extensions: Extension Definitions", RFC 6066, 280 DOI 10.17487/RFC6066, January 2011, 281 . 283 [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, 284 DOI 10.17487/RFC6454, December 2011, 285 . 287 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 288 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 289 DOI 10.17487/RFC7540, May 2015, 290 . 292 5.2. Informative References 294 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 295 DOI 10.17487/RFC5988, October 2010, 296 . 298 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 299 Protocol (HTTP/1.1): Message Syntax and Routing", 300 RFC 7230, DOI 10.17487/RFC7230, June 2014, 301 . 303 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP 304 Alternative Services", RFC 7838, DOI 10.17487/RFC7838, 305 April 2016, . 307 Appendix A. Non-Normative Processing Algorithm 309 The following algorithm illustrates how a client could handle 310 received ORIGIN frames: 312 1. If the client is configured to use a proxy for the connection, 313 ignore the frame and stop processing. 315 2. If the connection is not identified with the "h2" protocol 316 identifier or another protocol that has explicitly opted into 317 this specification, ignore the frame and stop processing. 319 3. If the frame occurs upon any stream except stream 0, ignore the 320 frame and stop processing. 322 4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the 323 frame and stop processing. 325 5. If no previous ORIGIN frame on the connection has reached this 326 step, initialise the Origin Set as per Section 2.3. 328 6. For each Origin field "origin_raw" in the frame payload: 330 1. Parse "origin_raw" as an ASCII serialization of an origin 331 ([RFC6454], Section 6.2) and let the result be 332 "parsed_origin". If parsing fails, skip to the next 333 "origin_raw". 335 2. Add "parsed_origin" to the Origin Set. 337 Appendix B. Operational Considerations for Servers 339 The ORIGIN frame allows a server to indicate for which origins a 340 given connection ought be used. 342 For example, it can be used to inform the client that the connection 343 is to only be used for the SNI-based origin, by sending an empty 344 ORIGIN frame. Or, a larger number of origins can be indicated by 345 including a payload. 347 Generally, this information is most useful to send before sending any 348 part of a response that might initiate a new connection; for example, 349 "Link" headers [RFC5988] in a response HEADERS, or links in the 350 response body. 352 Therefore, the ORIGIN frame ought be sent as soon as possible on a 353 connection, ideally before any HEADERS or PUSH_PROMISE frames. 355 However, if it's desirable to associate a large number of origins 356 with a connection, doing so might introduce end-user perceived 357 latency, due to their size. As a result, it might be necessary to 358 select a "core" set of origins to send initially, expanding the set 359 of origins the connection is used for with subsequent ORIGIN frames 360 later (e.g., when the connection is idle). 362 Senders should note that, as per [RFC6454] Section 4, the values in 363 an ORIGIN header need to be case-normalised before serialisation. 365 Finally, servers that allow alternative services [RFC7838] will need 366 to explicitly advertise those origins when sending ORIGIN, because 367 the default contents of the Origin Set (as per Section 2.3) do not 368 contain any Alternative Services, even if they have been used 369 previously on the connection. 371 Authors' Addresses 373 Mark Nottingham 374 Akamai 376 Email: mnot@mnot.net 377 URI: https://www.mnot.net/ 378 Erik Nygren 379 Akamai 381 Email: nygren@akamai.com