From 03b479955f624ce20fcf15a30810129d67e9a934 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Wed, 1 Feb 2017 17:38:16 +1100 Subject: [PATCH 01/28] - Change the initial origin set to just SNI - Relax DNS requirements when ORIGIN is received --- draft-ietf-httpbis-origin-frame.md | 49 +++++++++++++++++++++--------- 1 file changed, 35 insertions(+), 14 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 2cd07d355..05304a1b7 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -58,6 +58,11 @@ Using a status code in this manner allows clients to recover from misdirected re penalty of adding latency. To address that, this specification defines a new HTTP/2 frame type, "ORIGIN", to allow servers to indicate what origins a connection is usable for. +Additionally, experience has shown that HTTP/2's requirement to establish server authority using +both DNS and the server's certificate is onerous. This specification relaxes the requirement to +check DNS when the ORIGIN frame is in use. + + ## Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", @@ -90,7 +95,7 @@ Origin: The ORIGIN frame defines the following flags: CLEAR (0x1): -: Indicates that the Origin Set MUST be reset to an empty set before processing the contents of the frame it occurs upon. +: Indicates that the Origin Set MUST be reset to an empty before processing the contents of the frame it occurs upon. REMOVE (0x2): : 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. @@ -101,41 +106,58 @@ REMOVE (0x2): 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 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. +When a connection is first established, its Origin Set is defined to be the origin composed from: + - Scheme: "https" + - Host: the value sent in Server Name Indication {{!RFC6066}} + - Port: the local port of the connection on the server + +If SNI is not sent, the Origin Set is empty when the connection is established. The ORIGIN frame allows the server to modify the Origin Set. In particular: 1. A server can add to its members by sending an ORIGIN frame (without any flags set); -2. A server can prune one or more origins from it by sending an ORIGIN frame with the REMOVE flag set; +2. A server can prune one or more origins from it by sending them in an ORIGIN frame with the REMOVE flag set; 3. 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. 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. +for the added origins (in the sense of {{!RFC7540}}, Section 10.1) on its own; see {{authority}}. + + +## Establishing Authority and Coalescing with ORIGIN {#authority} + +{{RFC7540}}, Section 10.1 uses both DNS and the presented TLS certificate to establish the +authority of an origin server, just as HTTP/1.1 does in {{RFC7230}}. + +Upon receiving an ORIGIN frame on a connection, clients that implement this specification are +released from the requirement to establish authority for a given origin using DNS, for that +connection. However, they MUST still establish authority using the certificate, as described in +{{RFC7540}} Section 9.1.1. -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. +Once such a frame is received, an implementing client MUST NOT use that connection for a given +origin unless it appears in the connection's Origin Set. Implementing clients SHOULD use a +connection for all origins which it is authoritative for, if they are included in its Origin Set. -## Processing ORIGIN Frames +## Processing ORIGIN Frames {#process} The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame can safely ignore it upon receipt. -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. +When received by an implementing client, it is used to manipulate the Origin Set (see {{set}}). -The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. +The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST +be ignored. 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. The following algorithm illustrates how a client can handle received ORIGIN frames: -1. If the client is configured to use a proxy, ignore the frame and stop processing. +1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing. 2. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. 3. If the CLEAR flag is set, remove all members from the Origin Set. 4. For each Origin field `origin_raw` in the frame payload: - 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. + 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. 2. 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`. 3. Otherwise, add `parsed_origin` to the Origin Set. @@ -143,7 +165,6 @@ The following algorithm illustrates how a client can handle received ORIGIN fram # Security Considerations Clients that blindly trust the ORIGIN frame's contents will be 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. +attacks. --- back From ac5a5e452582d72ec1808e7fbd4049d0774696e0 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Wed, 1 Feb 2017 17:45:29 +1100 Subject: [PATCH 02/28] fix some refs --- draft-ietf-httpbis-origin-frame.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 05304a1b7..85b8cafdb 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -125,13 +125,13 @@ for the added origins (in the sense of {{!RFC7540}}, Section 10.1) on its own; s ## Establishing Authority and Coalescing with ORIGIN {#authority} -{{RFC7540}}, Section 10.1 uses both DNS and the presented TLS certificate to establish the -authority of an origin server, just as HTTP/1.1 does in {{RFC7230}}. +{{!RFC7540}}, Section 10.1 uses both DNS and the presented TLS certificate to establish the +authority of an origin server, just as HTTP/1.1 does in {{?RFC7230}}. Upon receiving an ORIGIN frame on a connection, clients that implement this specification are released from the requirement to establish authority for a given origin using DNS, for that connection. However, they MUST still establish authority using the certificate, as described in -{{RFC7540}} Section 9.1.1. +{{!RFC7540}} Section 9.1.1. Once such a frame is received, an implementing client MUST NOT use that connection for a given origin unless it appears in the connection's Origin Set. Implementing clients SHOULD use a From 241ce50734215f15c7af2e65921e710d8f977638 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Wed, 1 Feb 2017 18:53:48 +1100 Subject: [PATCH 03/28] missing 'set' --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 85b8cafdb..daf5b7b7b 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -95,7 +95,7 @@ Origin: The ORIGIN frame defines the following flags: CLEAR (0x1): -: Indicates that the Origin Set MUST be reset to an empty before processing the contents of the frame it occurs upon. +: Indicates that the Origin Set MUST be reset to an empty set before processing the contents of the frame it occurs upon. REMOVE (0x2): : 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. From eaa6a4bd547bcee8eabc9d72a535eea4f68c1aaa Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 11:55:13 +1100 Subject: [PATCH 04/28] note unicode --- writeups/5987bis.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/writeups/5987bis.md b/writeups/5987bis.md index 4be22d8f1..9561e5543 100644 --- a/writeups/5987bis.md +++ b/writeups/5987bis.md @@ -25,3 +25,9 @@ the document changes are controversial. The author has confirmed that to their direct, personal knowlege, all IPR related to this document has already been disclosed. + + +### 4. Other Information + +Note that this draft has non-ASCII content in it, and therefore needs to be published using the +new, Unicode-enabled process. \ No newline at end of file From de47d40db2c9ca06eb98678e45ebab3f0253fda4 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 13:19:24 +1100 Subject: [PATCH 05/28] rewrite after discussion --- draft-ietf-httpbis-origin-frame.md | 117 ++++++++++++++++++----------- 1 file changed, 72 insertions(+), 45 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index daf5b7b7b..61af15b5e 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -75,11 +75,13 @@ The ORIGIN HTTP/2 frame ({{!RFC7540}}, Section 4) allows a server to indicate wh {{!RFC6454}} the server would like the client to consider as members of the Origin Set ({{set}}) for the connection it occurs within. +## Syntax {#syntax} + The ORIGIN frame type is 0xb (decimal 11). ~~~~ +-------------------------------+-------------------------------+ -| Origin-Len (16) | Origin? (*) ... +| Origin-Len (16) | ASCII-Origin? (*) ... +-------------------------------+-------------------------------+ ~~~~ @@ -92,13 +94,42 @@ Origin-Len: Origin: : An optional sequence of characters containing the ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) that the sender believes this connection is or could be authoritative for. -The ORIGIN frame defines the following flags: +The ORIGIN frame does not define any flags. + + +## Processing ORIGIN Frames {#process} + +The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame +can safely ignore it upon receipt. + +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}}). + +The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST +be ignored. + +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. + +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. + +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. + +Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be +case-normalised before serialisation. + +Once parsed, the value MUST have: -CLEAR (0x1): -: Indicates that the Origin Set MUST be reset to an empty set before processing the contents of the frame it occurs upon. +* a scheme of "https", +* 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 +* a port that reflects the connection's local port on the server. -REMOVE (0x2): -: 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. +If any of these requirements are violated, the client MUST ignore the field. + +See {{algo}} for an illustrative algorithm for processing ORIGIN frames. ## The Origin Set {#set} @@ -106,65 +137,61 @@ REMOVE (0x2): 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 a connection is first established, its Origin Set is defined to be the origin composed from: +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}} + - Host: the value sent in Server Name Indication ({{!RFC6066}} Section 3), converted to lower case - Port: the local port of the connection on the server -If SNI is not sent, the Origin Set is empty when the connection is established. +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}}. -The ORIGIN frame allows the server to modify the Origin Set. In particular: +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. -1. A server can add to its members by sending an ORIGIN frame (without any flags set); -2. A server can prune one or more origins from it by sending them in an ORIGIN frame with the REMOVE flag set; -3. 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. -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; see {{authority}}. +## Authority and Coalescing with ORIGIN {#authority} +{{!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. -## Establishing Authority and Coalescing with ORIGIN {#authority} +Upon receiving an ORIGIN frame on a connection, clients that implement this specification change +these behaviors in the following ways: -{{!RFC7540}}, Section 10.1 uses both DNS and the presented TLS certificate to establish the -authority of an origin server, just as HTTP/1.1 does in {{?RFC7230}}. +* 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. -Upon receiving an ORIGIN frame on a connection, clients that implement this specification are -released from the requirement to establish authority for a given origin using DNS, for that -connection. However, they MUST still establish authority using the certificate, as described in -{{!RFC7540}} Section 9.1.1. +* 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. -Once such a frame is received, an implementing client MUST NOT use that connection for a given -origin unless it appears in the connection's Origin Set. Implementing clients SHOULD use a -connection for all origins which it is authoritative for, if they are included in its Origin Set. +# Security Considerations -## Processing ORIGIN Frames {#process} +Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of +attacks. See {{authority}} for mitigations. -The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame -can safely ignore it upon receipt. +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. -When received by an implementing client, it is used to manipulate the Origin Set (see {{set}}). +--- back -The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST -be ignored. -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. +# Non-Normative Processing Algoritm {#algo} -The following algorithm illustrates how a client can handle received ORIGIN frames: +The following algorithm illustrates how a client could handle received ORIGIN frames: 1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing. -2. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. -3. If the CLEAR flag is set, remove all members from the Origin Set. +2. If the connection is not running under TLS or does not present Server Name Indication (SNI) {{!RFC6006}}, ignore the frame and stop processing. +3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. 4. For each Origin field `origin_raw` in the frame payload: 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. - 2. 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`. - 3. Otherwise, add `parsed_origin` to the Origin Set. + 2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`. + 3. If the `host` of `parsed_origin` does not match a `subjectAltName` in the connection's presented certificate (using the wildcard rules defined in {{!RFC2818}}, Section 3.1), skip to the next `origin_raw`. + 4. If the `port` of `parsed_origin` does not match the connection's local port, skip to the next `origin_raw`. + 5. Add `parsed_origin` to the Origin Set. - -# Security Considerations - -Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of -attacks. - ---- back From 8171ff1cd2d252a7a25980c510f1e9401b6a4339 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 13:23:47 +1100 Subject: [PATCH 06/28] fix ref --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 61af15b5e..8d4385ad5 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -116,7 +116,7 @@ The ORIGIN frame is processed hop-by-hop. An intermediary MUST NOT forward ORIGI configured to use a proxy MUST ignore any ORIGIN frames received from it. 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. +origin ({{!RFC6454}}, Section 6.2). If parsing fails, the field MUST be ignored. Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be case-normalised before serialisation. From 835e8d99bc357101a8869a1415b4cdacb69f2a15 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 13:30:44 +1100 Subject: [PATCH 07/28] Update 5987bis.md --- writeups/5987bis.md | 6 ------ 1 file changed, 6 deletions(-) diff --git a/writeups/5987bis.md b/writeups/5987bis.md index 9561e5543..4be22d8f1 100644 --- a/writeups/5987bis.md +++ b/writeups/5987bis.md @@ -25,9 +25,3 @@ the document changes are controversial. The author has confirmed that to their direct, personal knowlege, all IPR related to this document has already been disclosed. - - -### 4. Other Information - -Note that this draft has non-ASCII content in it, and therefore needs to be published using the -new, Unicode-enabled process. \ No newline at end of file From d4bf661368ff53a5a49c4d67e4c93348513c8a42 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 13:35:00 +1100 Subject: [PATCH 08/28] local -> remote --- draft-ietf-httpbis-origin-frame.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 8d4385ad5..af53703d2 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -125,7 +125,7 @@ Once parsed, the value MUST have: * a scheme of "https", * 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 -* a port that reflects the connection's local port on the server. +* a port that reflects the connection's remote port on the client. If any of these requirements are violated, the client MUST ignore the field. @@ -192,6 +192,6 @@ The following algorithm illustrates how a client could handle received ORIGIN fr 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. 2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`. 3. If the `host` of `parsed_origin` does not match a `subjectAltName` in the connection's presented certificate (using the wildcard rules defined in {{!RFC2818}}, Section 3.1), skip to the next `origin_raw`. - 4. If the `port` of `parsed_origin` does not match the connection's local port, skip to the next `origin_raw`. + 4. If the `port` of `parsed_origin` does not match the connection's remote port, skip to the next `origin_raw`. 5. Add `parsed_origin` to the Origin Set. From 6529f681194b5d70612865b8dd1a36aeea7451eb Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 13:38:41 +1100 Subject: [PATCH 09/28] add placeholder for IANA considerations. --- draft-ietf-httpbis-origin-frame.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index af53703d2..84c3e9d8e 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -168,6 +168,11 @@ these behaviors in the following ways: * 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. +# IANA Considerations + +TBD. + + # Security Considerations Clients that blindly trust the ORIGIN frame's contents will be vulnerable to a large number of From 6b932b2a5fca88705afabb23f938afe8d81129fe Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 13:39:02 +1100 Subject: [PATCH 10/28] I spel gud --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 84c3e9d8e..9fc3da276 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -186,7 +186,7 @@ order to coalesce connections to the target onto their existing connection. --- back -# Non-Normative Processing Algoritm {#algo} +# Non-Normative Processing Algorithm {#algo} The following algorithm illustrates how a client could handle received ORIGIN frames: From 91b2a4e57d70967452c9e56617ff40ac27b1c1f8 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 14:55:03 +1100 Subject: [PATCH 11/28] add "note that..." --- draft-ietf-httpbis-origin-frame.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 9fc3da276..b6815326b 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -167,6 +167,10 @@ these behaviors in the following ways: * 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. +Note that this does not prevent clients from performing other certificate checks as required or +allowed, either at connection time or when processing ORIGIN. See {{!RFC7540}} Section 9.1.1 for +more information. + # IANA Considerations From 227694d092a8ce0fc88d044bdba8c0e4530eb2a9 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 2 Feb 2017 17:21:29 +1100 Subject: [PATCH 12/28] more HTTPS getout clause --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index b6815326b..85d611149 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -195,7 +195,7 @@ order to coalesce connections to the target onto their existing connection. The following algorithm illustrates how a client could handle received ORIGIN frames: 1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing. -2. If the connection is not running under TLS or does not present Server Name Indication (SNI) {{!RFC6006}}, ignore the frame and stop processing. +2. If the connection is not running under TLS, does not present Server Name Indication (SNI) {{!RFC6006}}, or the connection does not otherwise meet the requirements set by standards or the client implementation, ignore the frame and stop processing. 3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. 4. For each Origin field `origin_raw` in the frame payload: 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. From 66463b0fc1da7d00ba5ba44c6513db4cd2b0209e Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 10:46:11 +1100 Subject: [PATCH 13/28] - Reserve some flags for backwards-incompatible changes - Note impact on Server Push - Small cleanups --- draft-ietf-httpbis-origin-frame.md | 30 ++++++++++++++++++++++-------- 1 file changed, 22 insertions(+), 8 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 85d611149..97301691b 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -89,12 +89,13 @@ The ORIGIN frame's payload contains the following fields, sets of which may be r frame to indicate multiple origins: Origin-Len: -: An unsigned, 16-bit integer indicating the length, in octets, of the Origin field. +: An unsigned, 16-bit integer indicating the length, in octets, of the ASCII-Origin field. Origin: : An optional sequence of characters containing the ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) that the sender believes this connection is or could be authoritative for. -The ORIGIN frame does not define any flags. +The ORIGIN frame does not define any flags. However, future updates to this specification MAY +define flags. See {{process}}. ## Processing ORIGIN Frames {#process} @@ -112,6 +113,13 @@ Likewise, the ORIGIN frame is only valid on connections with the "h2" protocol i specifically nominated by the protocol's definition; it MUST be ignored when received on a connection with the "h2c" protocol identifier. +This specification does not define any flags for the ORIGIN frame, but future updates might use +them to change its semantics. The first four flags (0x1, 0x2, 0x4 and 0x8) are reserved for +backwards-incompatible changes, and therefore when any of them are set, the ORIGIN frame containing +them MUST be ignored by clients conforming to this specification. The remaining flags are reserved +for backwards-compatible changes, and do not affect processing by clients conformant to this +specification. + 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. @@ -127,7 +135,8 @@ Once parsed, the value MUST have: * 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 * a port that reflects the connection's remote port on the client. -If any of these requirements are violated, the client MUST ignore the field. +If any of these requirements are violated, the client MUST ignore the field (but still continue +processing the frame). See {{algo}} for an illustrative algorithm for processing ORIGIN frames. @@ -152,20 +161,24 @@ The Origin Set is also affected by the 421 (Misdirected Request) response status 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. +Note that the Origin Set does not affect existing streams on a connection in any way. + -## Authority and Coalescing with ORIGIN {#authority} +## Authority, Push and Coalescing with ORIGIN {#authority} {{!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. +origin server, if it is authoritative. This affects what requests can be sent on the connection, both in HEADERS frame by the client and as PUSH_PROMISE frames from the server. Upon receiving an ORIGIN frame on a connection, clients that implement this specification change these behaviors in the following ways: -* 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. +* Clients 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. + +* Clients sending a new request SHOULD use an existing connection if the request's origin is in that connection's Origin Set, unless there are operational reasons for creating a new connection. -* 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. +* Clients MUST use the Origin Set to determine whether a received PUSH_PROMISE is authoritative, as described in {{!RFC7540}}, Section 8.2.2. Note that this does not prevent clients from performing other certificate checks as required or allowed, either at connection time or when processing ORIGIN. See {{!RFC7540}} Section 9.1.1 for @@ -197,7 +210,8 @@ The following algorithm illustrates how a client could handle received ORIGIN fr 1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing. 2. If the connection is not running under TLS, does not present Server Name Indication (SNI) {{!RFC6006}}, or the connection does not otherwise meet the requirements set by standards or the client implementation, ignore the frame and stop processing. 3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. -4. For each Origin field `origin_raw` in the frame payload: +4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the frame and stop processing. +5. For each Origin field `origin_raw` in the frame payload: 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. 2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`. 3. If the `host` of `parsed_origin` does not match a `subjectAltName` in the connection's presented certificate (using the wildcard rules defined in {{!RFC2818}}, Section 3.1), skip to the next `origin_raw`. From a77c32213b64a21e3aed4014fad4026cd305d15a Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 10:48:37 +1100 Subject: [PATCH 14/28] add IANA considerations --- draft-ietf-httpbis-origin-frame.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 97301691b..a2059a7e2 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -187,7 +187,11 @@ more information. # IANA Considerations -TBD. +This specification adds an entry to the "HTTP/2 Frame Type" registry. + +* Frame Type: ORIGIN +* Code: 0xb +* Specification: [this document] # Security Considerations From 4d3cf21550ed4dc84cd6d802e5ae24e7a01c412f Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 10:55:01 +1100 Subject: [PATCH 15/28] Martin's suggestion (modified) --- draft-ietf-httpbis-origin-frame.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index a2059a7e2..4e322bc68 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -218,7 +218,11 @@ The following algorithm illustrates how a client could handle received ORIGIN fr 5. For each Origin field `origin_raw` in the frame payload: 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. 2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`. - 3. If the `host` of `parsed_origin` does not match a `subjectAltName` in the connection's presented certificate (using the wildcard rules defined in {{!RFC2818}}, Section 3.1), skip to the next `origin_raw`. + 3. If the certificate presented by the server is not valid for the `host` of `parsed_origin` (see below), skip to the next `origin_raw`. 4. If the `port` of `parsed_origin` does not match the connection's remote port, skip to the next `origin_raw`. 5. Add `parsed_origin` to the Origin Set. +The certificate presented by the server is valid for a host if it passes the checks that the client +would perform when forming a new TLS connection to the origin. This includes verifying that the +host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules +defined in {{!RFC2818}}). From b2a7bc2cdd8627d19fb71c3ed44df533be096da6 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 11:06:53 +1100 Subject: [PATCH 16/28] change TLS step --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 4e322bc68..c8e2203dc 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -212,7 +212,7 @@ order to coalesce connections to the target onto their existing connection. The following algorithm illustrates how a client could handle received ORIGIN frames: 1. If the client is configured to use a proxy for the connection, ignore the frame and stop processing. -2. If the connection is not running under TLS, does not present Server Name Indication (SNI) {{!RFC6006}}, or the connection does not otherwise meet the requirements set by standards or the client implementation, ignore the frame and stop processing. +2. If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing. 3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. 4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the frame and stop processing. 5. For each Origin field `origin_raw` in the frame payload: From f27c5e09ea63a6b357fb6a18c8da307a5f33b073 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 11:10:34 +1100 Subject: [PATCH 17/28] Tweak "initialised" --- draft-ietf-httpbis-origin-frame.md | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index c8e2203dc..5da6eb7a8 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -103,8 +103,9 @@ define flags. See {{process}}. The ORIGIN frame is a non-critical extension to HTTP/2. Endpoints that do not support this frame can safely ignore it upon receipt. -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}}). +When received by an implementing client, it is used to initialise and manipulate the Origin Set +(see {{set}}), thereby changing how the client establishes authority for origin servers (see +{{authority}}). The origin frame MUST be sent on stream 0; an ORIGIN frame on any other stream is invalid and MUST be ignored. @@ -146,8 +147,9 @@ See {{algo}} for an illustrative algorithm for processing ORIGIN frames. 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: +By default, a connections's Origin Set is uninitialised. When an ORIGIN frame is first received and +successfully processed 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 @@ -171,8 +173,8 @@ server(s) that a connection is authoritative for, just as HTTP/1.1 does in {{?RF Furthermore, {{!RFC7540}} Section 9.1.1 explicitly allows a connection to be used for more than one origin server, if it is authoritative. This affects what requests can be sent on the connection, both in HEADERS frame by the client and as PUSH_PROMISE frames from the server. -Upon receiving an ORIGIN frame on a connection, clients that implement this specification change -these behaviors in the following ways: +Once an Origin Set has been initialised for a connection, clients that implement this +specification change these behaviors in the following ways: * Clients 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. @@ -215,7 +217,8 @@ The following algorithm illustrates how a client could handle received ORIGIN fr 2. If the connection is not identified with the "h2" protocol identifier or another protocol that has explicitly opted into this specification, ignore the frame and stop processing. 3. If the frame occurs upon any stream except stream 0, ignore the frame and stop processing. 4. If any of the flags 0x1, 0x2, 0x4 or 0x8 are set, ignore the frame and stop processing. -5. For each Origin field `origin_raw` in the frame payload: +5. If no previous ORIGIN frame on the connection has reached this step, initialise the Origin Set as per {{set}}. +6. For each Origin field `origin_raw` in the frame payload: 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. 2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`. 3. If the certificate presented by the server is not valid for the `host` of `parsed_origin` (see below), skip to the next `origin_raw`. From 31fea62feac40712165efe8fce03cc0f149e4ac6 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 11:28:42 +1100 Subject: [PATCH 18/28] add operational considerations --- draft-ietf-httpbis-origin-frame.md | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 5da6eb7a8..422ff5a12 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -229,3 +229,24 @@ The certificate presented by the server is valid for a host if it passes the che would perform when forming a new TLS connection to the origin. This includes verifying that the host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules defined in {{!RFC2818}}). + + +# Operational Considerations for Servers {#server-ops} + +The ORIGIN frame allows a server to indicate what for origins a given connection ought be used. + +For example, it can be used to inform the client that the connection is to only be used for the +SNI-based origin, by sending an empty ORIGIN frame. Or, a larger number of origins can be indicated +by including a payload. + +Generally, this information is most useful to send before sending any part of a response that might +initiate a new connection; for example, `Link` headers {{?RFC5988}} in a response HEADERS, or links +in the response body. + +Therefore, the ORIGIN frame ought be sent as soon as possible on a connection, ideally before any +HEADERS or PUSH_PROMISE frames. + +However, if it's desirable to associate a large number of origins with a connection, doing so might +introduce end-user perceived latency, due to their size. As a result, it might be necessary to +select a "core" set of origins to send initially, expanding the set of origins the connection is +used for with subsequent ORIGIN frames later (e.g., when the connection is idle). From 0b6affac60d57b486664af7d8a94047cf9e81bfd Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 11:32:48 +1100 Subject: [PATCH 19/28] talk about conn de-duplication --- draft-ietf-httpbis-origin-frame.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 422ff5a12..9d08dc403 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -186,6 +186,11 @@ Note that this does not prevent clients from performing other certificate checks allowed, either at connection time or when processing ORIGIN. See {{!RFC7540}} Section 9.1.1 for more information. +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 satisified. + # IANA Considerations From 8afa09b580bf52df234522ce8397e67ff8274e76 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Fri, 3 Feb 2017 11:35:01 +1100 Subject: [PATCH 20/28] clarify --- draft-ietf-httpbis-origin-frame.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 9d08dc403..34b18a03b 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -163,20 +163,20 @@ The Origin Set is also affected by the 421 (Misdirected Request) response status 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. -Note that the Origin Set does not affect existing streams on a connection in any way. - ## Authority, Push and Coalescing with ORIGIN {#authority} {{!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. This affects what requests can be sent on the connection, both in HEADERS frame by the client and as PUSH_PROMISE frames from the server. +origin server, if it is authoritative. This affects what requests can be sent on the connection, +both in HEADERS frame by the client and as PUSH_PROMISE frames from the server. -Once an Origin Set has been initialised for a connection, clients that implement this -specification change these behaviors in the following ways: +Once an Origin Set has been initialised for a connection, clients that implement this specification +change these behaviors in the following ways: -* Clients 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. +* Clients MUST NOT consult DNS to establish the connection's authority for new requests. The TLS + certificate MUST be used to do so, as described in {{!RFC7540}} Section 9.1.1. * Clients sending a new request SHOULD use an existing connection if the request's origin is in that connection's Origin Set, unless there are operational reasons for creating a new connection. From cc16f7dee4a9d68f93158da9d85e2fe6d21f086a Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Sat, 4 Feb 2017 11:30:00 +1100 Subject: [PATCH 21/28] Patrick's suggestion about hop-by-hop --- draft-ietf-httpbis-origin-frame.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 34b18a03b..9ac20955d 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -121,8 +121,9 @@ them MUST be ignored by clients conforming to this specification. The remaining for backwards-compatible changes, and do not affect processing by clients conformant to this specification. -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. +The ORIGIN frame describes a property of the connection, and therefore 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. 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. From 5a9a6677071a24bd0d97d9ba5202f64789e422e3 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Sat, 4 Feb 2017 11:31:32 +1100 Subject: [PATCH 22/28] deweert suggestion --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 9ac20955d..befeb4abc 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -239,7 +239,7 @@ defined in {{!RFC2818}}). # Operational Considerations for Servers {#server-ops} -The ORIGIN frame allows a server to indicate what for origins a given connection ought be used. +The ORIGIN frame allows a server to indicate for which origins a given connection ought be used. For example, it can be used to inform the client that the connection is to only be used for the SNI-based origin, by sending an empty ORIGIN frame. Or, a larger number of origins can be indicated From 93d2b92c9e05087144c5e8b0ee2b03b1b37c1866 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Sat, 4 Feb 2017 11:34:35 +1100 Subject: [PATCH 23/28] add 5280 ref --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index befeb4abc..6665c3738 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -234,7 +234,7 @@ The following algorithm illustrates how a client could handle received ORIGIN fr The certificate presented by the server is valid for a host if it passes the checks that the client would perform when forming a new TLS connection to the origin. This includes verifying that the host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules -defined in {{!RFC2818}}). +defined in {{!RFC2818}}; see also {{!RFC5280}} Section 4.2.1.6). # Operational Considerations for Servers {#server-ops} From 213b958c421f2077ea86295d3b3ae753bfb04317 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Sat, 4 Feb 2017 11:36:09 +1100 Subject: [PATCH 24/28] Add motivation --- draft-ietf-httpbis-origin-frame.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 6665c3738..004786e5a 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -60,7 +60,8 @@ penalty of adding latency. To address that, this specification defines a new HTT Additionally, experience has shown that HTTP/2's requirement to establish server authority using both DNS and the server's certificate is onerous. This specification relaxes the requirement to -check DNS when the ORIGIN frame is in use. +check DNS when the ORIGIN frame is in use. Doing so has additional benefits, such as removing the +latency associated with some DNS lookups, and improving DNS privacy. ## Notational Conventions From 23157274e9424535938f81f3ee1e98b2e53e55dd Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 7 Feb 2017 11:50:24 +1100 Subject: [PATCH 25/28] defer checks on origin to use takes care of Patrick's alt-svc concern --- draft-ietf-httpbis-origin-frame.md | 29 +++++++---------------------- 1 file changed, 7 insertions(+), 22 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 004786e5a..06de9c069 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -132,15 +132,6 @@ origin ({{!RFC6454}}, Section 6.2). If parsing fails, the field MUST be ignored. Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be case-normalised before serialisation. -Once parsed, the value MUST have: - -* a scheme of "https", -* 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 -* a port that reflects the connection's remote port on the client. - -If any of these requirements are violated, the client MUST ignore the field (but still continue -processing the frame). - See {{algo}} for an illustrative algorithm for processing ORIGIN frames. @@ -178,20 +169,22 @@ Once an Origin Set has been initialised for a connection, clients that implement change these behaviors in the following ways: * Clients MUST NOT consult DNS to establish the connection's authority for new requests. The TLS - certificate MUST be used to do so, as described in {{!RFC7540}} Section 9.1.1. + certificate MUST stil be used to do so, as described in {{!RFC7540}} Section 9.1.1. * Clients sending a new request SHOULD use an existing connection if the request's origin is in that connection's Origin Set, unless there are operational reasons for creating a new connection. * Clients MUST use the Origin Set to determine whether a received PUSH_PROMISE is authoritative, as described in {{!RFC7540}}, Section 8.2.2. -Note that this does not prevent clients from performing other certificate checks as required or -allowed, either at connection time or when processing ORIGIN. See {{!RFC7540}} Section 9.1.1 for -more information. +Note that clients are still required to perform checks on the certificate presented by the server +for each origin that a connection is used for; see {{!RFC7540}} Section 9.1.1 for more information. +This includes verifying that the host matches a `dNSName` value from the certificate +`subjectAltName` field (using the wildcard rules defined in {{!RFC2818}}; see also {{!RFC5280}} +Section 4.2.1.6). 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 satisified. +another connection's Origin Set, and SHOULD close it once all outstanding requests are satisfied. # IANA Considerations @@ -227,16 +220,8 @@ The following algorithm illustrates how a client could handle received ORIGIN fr 5. If no previous ORIGIN frame on the connection has reached this step, initialise the Origin Set as per {{set}}. 6. For each Origin field `origin_raw` in the frame payload: 1. Parse `origin_raw` as an ASCII serialization of an origin ({{!RFC6454}}, Section 6.2) and let the result be `parsed_origin`. If parsing fails, skip to the next `origin_raw`. - 2. If the `scheme` of `parsed_origin` is not "https", skip to the next `origin_raw`. - 3. If the certificate presented by the server is not valid for the `host` of `parsed_origin` (see below), skip to the next `origin_raw`. - 4. If the `port` of `parsed_origin` does not match the connection's remote port, skip to the next `origin_raw`. 5. Add `parsed_origin` to the Origin Set. -The certificate presented by the server is valid for a host if it passes the checks that the client -would perform when forming a new TLS connection to the origin. This includes verifying that the -host matches a `dNSName` value from the certificate `subjectAltName` field (using the wildcard rules -defined in {{!RFC2818}}; see also {{!RFC5280}} Section 4.2.1.6). - # Operational Considerations for Servers {#server-ops} From 85209385ab88ed6d90f2507d47fc2e7865516a6e Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 7 Feb 2017 11:51:12 +1100 Subject: [PATCH 26/28] move note about case to server-ops --- draft-ietf-httpbis-origin-frame.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 06de9c069..d6489b38f 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -129,9 +129,6 @@ ORIGIN frames received from it. 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. -Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be -case-normalised before serialisation. - See {{algo}} for an illustrative algorithm for processing ORIGIN frames. @@ -242,3 +239,6 @@ However, if it's desirable to associate a large number of origins with a connect introduce end-user perceived latency, due to their size. As a result, it might be necessary to select a "core" set of origins to send initially, expanding the set of origins the connection is used for with subsequent ORIGIN frames later (e.g., when the connection is idle). + +Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be +case-normalised before serialisation. From 6b3b76186c3eecbeace6bbd7bbbb8a040b502006 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Tue, 7 Feb 2017 13:15:42 +1100 Subject: [PATCH 27/28] correct port --- draft-ietf-httpbis-origin-frame.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index d6489b38f..97278ded6 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -143,7 +143,7 @@ origin, composed from: - Scheme: "https" - Host: the value sent in Server Name Indication ({{!RFC6066}} Section 3), converted to lower case - - Port: the local port of the connection on the server + - Port: the remote port of the connection (i.e., the server's port) 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}}. From e2083ad3938f7f335ef4051ce5edfb03259fdcd7 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Mon, 13 Feb 2017 16:20:07 +1100 Subject: [PATCH 28/28] Note interaction with Alt-Svc. as per Patrick --- draft-ietf-httpbis-origin-frame.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-httpbis-origin-frame.md b/draft-ietf-httpbis-origin-frame.md index 97278ded6..588ccc447 100644 --- a/draft-ietf-httpbis-origin-frame.md +++ b/draft-ietf-httpbis-origin-frame.md @@ -242,3 +242,7 @@ used for with subsequent ORIGIN frames later (e.g., when the connection is idle) Senders should note that, as per {{!RFC6454}} Section 4, the values in an ORIGIN header need to be case-normalised before serialisation. + +Finally, servers that allow alternative services {{?RFC7838}} will need to explicitly advertise +those origins when sending ORIGIN, because the default contents of the Origin Set (as per {{set}}) +do not contain any Alternative Services, even if they have been used previously on the connection.