serialization of an origin (RFC6454, Section 6.2) that the sender believes this connection is or could be authoritative for. <del> The ORIGIN frame defines the following flags: </del> <ins> The ORIGIN frame does not define any flags. </ins> <del> Indicates that the Origin Set MUST be reset to an empty set before processing the contents of the frame it occurs upon. </del> <ins> 2.2. </ins> <del> Indicates that the origin(s) carried in the payload must be removed from the Origin Set, if present; if not present, it/they have no effect. </del> <ins> The ORIGIN frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame can safely ignore it upon receipt. </ins> <del> 2.1. </del> <ins> When received by an implementing client, it is used to manipulate the Origin Set (see set), thereby changing how the client establishes authority for origin servers (see authority). </ins> <del> The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. </del> <ins> The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. </ins> <del> When a connection is first established, its Origin Set is defined to be those origins that the client would normally consider the connection authoritative for; see RFC7540, Section 10.1. </del> <ins> Likewise, the ORIGIN frame is only valid on connections with the "h2" protocol identifier, or when specifically nominated by the protocol's definition; it MUST be ignored when received on a connection with the "h2c" protocol identifier. </ins> <del> The ORIGIN frame allows the server to modify the Origin Set. In particular: </del> <ins> The ORIGIN frame is processed hop-by-hop.  An intermediary MUST NOT forward ORIGIN frames.  Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. </ins> <del> A server can add to its members by sending an ORIGIN frame (without any flags set); </del> <ins> Each ASCII-Origin field in the frame's payload MUST be parsed as an ASCII serialisation of an origin (RFC6454, Section 6.2).  If parsing fails, the field MUST be ignored. </ins> <del> A server can prune one or more origins from it by sending an ORIGIN frame with the REMOVE flag set; </del> <ins> Senders should note that, as per RFC6454 Section 4, the values in an ORIGIN header need to be case-normalised before serialisation. </ins> <del> A server can remove all its members and then add zero or more members by sending an ORIGIN frame with the CLEAR flag set and a payload containing the new origins. </del> <ins> Once parsed, the value MUST have: </ins> <del> Adding to the Origin Set (cases 1 and 3 above) does not imply that the connection is authoritative for the added origins (in the sense of RFC7540, Section 10.1) on its own; this MUST be established by some other mechanism. </del> <ins> a scheme of "https", </ins> <del> A client that implements this specification MUST NOT use a connection for a given origin unless that origin appears in the Origin Set for the connection, regardless of whether or not it believes that the connection is authoritative for that origin. </del> <ins> a host that is reflected in a "subjectAltName" of the connection's TLS certificate (using the wildcard rules defined in RFC2818, Section 3.1), and </ins> <del> 2.2. </del> <ins> a port that reflects the connection's remote port on the client. </ins> <del> The ORIGIN frame is a non-critical extension to HTTP/2.  Endpoints that do not support this frame can safely ignore it upon receipt. </del> <ins> If any of these requirements are violated, the client MUST ignore the field. </ins> <del> When received by a client, it can be used to inform HTTP/2 connection coalescing (see set), but does not relax the requirement there that the server is authoritative. </del> <ins> See algo for an illustrative algorithm for processing ORIGIN frames. </ins> <del> The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. </del> <ins> 2.3. </ins> <del> The ORIGIN frame is processed hop-by-hop.  An intermediary MUST NOT forward ORIGIN frames.  Clients configured to use a proxy MUST ignore any ORIGIN frames received from it. </del> <ins> The set of origins (as per RFC6454) that a given connection might be used for is known in this specification as the Origin Set. When an ORIGIN frame is first received by a client, the connection's Origin Set is defined to contain a single origin, composed from: Scheme: "https" Host: the value sent in Server Name Indication (RFC6066 Section 3), converted to lower case </ins> <del> The following algorithm illustrates how a client can handle received ORIGIN frames: </del> <ins> Port: the local port of the connection on the server </ins> <del> If the client is configured to use a proxy, ignore the frame and stop processing. </del> <ins> The contents of that ORIGIN frame (and subsequent ones) allows the server to incrementally add new origins to the Origin Set, as described in process. </ins> <del> If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. </del> <ins> The Origin Set is also affected by the 421 (Misdirected Request) response status code, defined in RFC7540 Section 9.1.2.  Upon receipt of a response with this status code, implementing clients MUST create the ASCII serialisation of the corresponding request's origin (as per RFC6454, Section 6.2) and remove it from the connection's Origin Set, if present. </ins> <del> If the CLEAR flag is set, remove all members from the Origin Set. </del> <ins> 2.4. </ins> <del> For each Origin field "origin_raw" in the frame payload: </del> <ins> RFC7540, Section 10.1 uses both DNS and the presented TLS certificate to establish the origin server(s) that a connection is authoritative for, just as HTTP/1.1 does in RFC7230.  Furthermore, RFC7540 Section 9.1.1 explicitly allows a connection to be used for more than one origin server, if it is authoritative. </ins> <del> Parse "origin_raw" as an ASCII serialization of an origin (RFC6454, Section 6.2) and let the result be "parsed_origin". </del> <ins> Upon receiving an ORIGIN frame on a connection, clients that implement this specification change these behaviors in the following ways: </ins> <del> If the REMOVE flag is set, remove any member of the Origin Set that is the same as "parsed_origin" (as per RFC6454, Section 5), and continue to the next "parsed_origin". </del> <ins> They MUST NOT consult DNS to establish authority for origins in the Origin Set. The TLS certificate MUST be used to do so, as described in RFC7540 Section 9.1.1. </ins> <del> Otherwise, add "parsed_origin" to the Origin Set. </del> <ins> Requests SHOULD use an existing connection if their origin is in that connection's Origin Set, unless there are operational reasons for creating a new connection. </ins> 3. <ins> TBD. 4. </ins> Clients that blindly trust the ORIGIN frame's contents will be <del> vulnerable to a large number of attacks; hence the reinforcement that this specification does not relax the requirement for server authority in RFC7540, Section 10.1. </del> <ins> vulnerable to a large number of attacks.  See authority for mitigations. Relaxing the requirement to consult DNS when determining authority for an origin means that an attacker who possesses a valid certificate no longer needs to be on-path to redirect traffic to them; instead of modifying DNS, they need only convince the user to visit another Web site, in order to coalesce connections to the target onto their existing connection. </ins> <del> 4.  References </del> <ins> 5.  References </ins> <del> 4.1.  URIs </del> <ins> 5.1.  URIs </ins> [1] https://lists.w3.org/Archives/Public/ietf-http-wg/