From bd25e8e9822595ca430bc658a48c5a632814aa19 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 22 Jan 2021 11:00:01 -0500 Subject: [PATCH 1/6] Refer to SEMANTICS for validation procedure --- draft-ietf-quic-http.md | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 79316d7523..44bc9c709f 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -295,21 +295,11 @@ authoritative server for an HTTP URL is discussed in Section 4.3 of The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority -component of the URL. - -If a server presents a valid certificate and proof that it controls the -corresponding private key, then a client will accept a secured TLS session with -that server as being authoritative for all origins with the "https" scheme and a -host identified in the certificate. The host must be listed either as the CN -field of the certificate subject or as a dNSName in the subjectAltName field of -the certificate; see {{!RFC6125}}. For a host that is an IP address, the client -MUST verify that the address appears as an iPAddress in the subjectAltName field -of the certificate. - -If the hostname or address is not present in the certificate, the client MUST -NOT consider the server authoritative for origins containing that hostname or -address. See Section 4.3 of {{!SEMANTICS}} for more detail on authoritative -access. +component of the URL. Upon receiving a server certificate in the TLS handshake, +the client MUST verify that the certificate is an acceptable match for the URI's +origin server using the process described in Section 4.3.4 of {{!SEMANTICS}}. If +the certificate cannot be verified with respect to the URI's origin server, the +client MUST NOT consider the server authoritative for that origin. A client MAY attempt access to a resource with an "https" URI by resolving the host identifier to an IP address, establishing a QUIC connection to that address From 7aabb8d3823dd50358739dcd4ba50114d24f05b9 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 22 Jan 2021 11:00:29 -0500 Subject: [PATCH 2/6] Expand reuse discussion --- draft-ietf-quic-http.md | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 44bc9c709f..e8c49ecc18 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -385,12 +385,25 @@ example, when a user navigates away from a particular web page) or until the server closes the connection. Once a connection exists to a server endpoint, this connection MAY be reused for -requests with multiple different URI authority components. Clients SHOULD NOT -open more than one HTTP/3 connection to a given host and port pair, where the -host is derived from a URI, a selected alternative service ({{!ALTSVC}}), or a -configured proxy. A client MAY open multiple HTTP/3 connections to the same IP -address and UDP port using different transport or TLS configurations but SHOULD -avoid creating multiple connections with the same configuration. +requests with multiple different URI authority components. To use an existing +connection for a new origin, clients MUST validate the certificate presented by +the server for the new origin server using the process described in Section +4.3.4 of {{!SEMANTICS}}. This implies that clients will need to retain the +server certificate chain; clients which do not do so will be unable to reuse the +connection for additional origins. + +If the certificate is not acceptable with regard to the new origin for any +reason, the connection MUST NOT be reused and a new connection SHOULD be +established for the new origin. If the reason the certificate cannot be +verified might apply to other origins already associated with the connection, +the client SHOULD re-validate the server certificate for those origins. + +Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port +pair, where the host is derived from a URI, a selected alternative service +({{!ALTSVC}}), or a configured proxy. A client MAY open multiple HTTP/3 +connections to the same IP address and UDP port using different transport or TLS +configurations but SHOULD avoid creating multiple connections with the same +configuration. Servers are encouraged to maintain open HTTP/3 connections for as long as possible but are permitted to terminate idle connections if necessary. When From d6b63803fdafd666cefc38a59bb0805ca9cfe3cc Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 22 Jan 2021 11:02:22 -0500 Subject: [PATCH 3/6] 421 in Semantics --- draft-ietf-quic-http.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index e8c49ecc18..892df67d42 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -414,8 +414,8 @@ processed and gracefully complete or terminate any necessary remaining tasks. A server that does not wish clients to reuse HTTP/3 connections for a particular origin can indicate that it is not authoritative for a request by sending a 421 -(Misdirected Request) status code in response to the request; see Section 9.1.2 -of {{?HTTP2}}. +(Misdirected Request) status code in response to the request; see Section 7.4 +of {{!SEMANTICS}}. # HTTP Request Lifecycle From 8b12ead95c23d295c06a855f7ba69903fe26ca6b Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Fri, 22 Jan 2021 11:05:44 -0500 Subject: [PATCH 4/6] Expand push equivalence to connection reuse --- draft-ietf-quic-http.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 892df67d42..731ee90772 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -856,7 +856,10 @@ following properties: - does not include a request body or trailer section The server MUST include a value in the ":authority" pseudo-header field for -which the server is authoritative; see {{connection-reuse}}. +which the server is authoritative. If the client has not yet validated the +connection for the origin indicated by the pushed request, it MUST perform the +same verification process it would do before sending a request for that origin +on the connection; see {{connection-reuse}}. Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that From 31a9f12a9b125f5ce0eaee03d9960ff69ead8163 Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Mon, 25 Jan 2021 12:27:15 -0500 Subject: [PATCH 5/6] Martin's feedback --- draft-ietf-quic-http.md | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 731ee90772..03a6345c74 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -295,7 +295,7 @@ authoritative server for an HTTP URL is discussed in Section 4.3 of The "https" scheme associates authority with possession of a certificate that the client considers to be trustworthy for the host identified by the authority -component of the URL. Upon receiving a server certificate in the TLS handshake, +component of the URI. Upon receiving a server certificate in the TLS handshake, the client MUST verify that the certificate is an acceptable match for the URI's origin server using the process described in Section 4.3.4 of {{!SEMANTICS}}. If the certificate cannot be verified with respect to the URI's origin server, the @@ -389,21 +389,25 @@ requests with multiple different URI authority components. To use an existing connection for a new origin, clients MUST validate the certificate presented by the server for the new origin server using the process described in Section 4.3.4 of {{!SEMANTICS}}. This implies that clients will need to retain the -server certificate chain; clients which do not do so will be unable to reuse the -connection for additional origins. +server certificate and any additional information needed to verify that +certificate; clients which do not do so will be unable to reuse the connection +for additional origins. If the certificate is not acceptable with regard to the new origin for any reason, the connection MUST NOT be reused and a new connection SHOULD be established for the new origin. If the reason the certificate cannot be verified might apply to other origins already associated with the connection, -the client SHOULD re-validate the server certificate for those origins. - -Clients SHOULD NOT open more than one HTTP/3 connection to a given host and port -pair, where the host is derived from a URI, a selected alternative service -({{!ALTSVC}}), or a configured proxy. A client MAY open multiple HTTP/3 -connections to the same IP address and UDP port using different transport or TLS -configurations but SHOULD avoid creating multiple connections with the same -configuration. +the client SHOULD re-validate the server certificate for those origins. For +instance, if validation of a certificate fails because the certificate has +expired or been revoked, this might be used to invalidate all other origins for +which that certificate was used to establish authority. + +Clients SHOULD NOT open more than one HTTP/3 connection to a given IP address +and UDP port, where the IP address and port might be derived from a URI, a +selected alternative service ({{!ALTSVC}}), a configured proxy, or name +resolution of any of these. A client MAY open multiple HTTP/3 connections to the +same IP address and UDP port using different transport or TLS configurations but +SHOULD avoid creating multiple connections with the same configuration. Servers are encouraged to maintain open HTTP/3 connections for as long as possible but are permitted to terminate idle connections if necessary. When From 041fd43fdf984ceafe336abff23ae34da50a19fc Mon Sep 17 00:00:00 2001 From: Mike Bishop Date: Tue, 26 Jan 2021 14:32:33 -0500 Subject: [PATCH 6/6] Failed verification == no good --- draft-ietf-quic-http.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-ietf-quic-http.md b/draft-ietf-quic-http.md index 03a6345c74..2c9304dbdf 100644 --- a/draft-ietf-quic-http.md +++ b/draft-ietf-quic-http.md @@ -863,7 +863,8 @@ The server MUST include a value in the ":authority" pseudo-header field for which the server is authoritative. If the client has not yet validated the connection for the origin indicated by the pushed request, it MUST perform the same verification process it would do before sending a request for that origin -on the connection; see {{connection-reuse}}. +on the connection; see {{connection-reuse}}. If this verification fails, +the client MUST NOT consider the server authoritative for that origin. Clients SHOULD send a CANCEL_PUSH frame upon receipt of a PUSH_PROMISE frame carrying a request that is not cacheable, is not known to be safe, that