Subject: [quicwg/base-drafts] Authoritative access in HTTP/3 (#3558)

From: Mike Bishop <[email-masked]>
Date: Mon, 30 Mar 2020 12:58:48 -0700

Fixes #253; fixes #2223.

- Clients MAY establish QUIC connections using the host and port indicated in the URL **for &quot;https&quot; URLs only**
- Non-&quot;https&quot; origins are able to be delegated using Alt-Svc

Cribs a lot of text from [Semantics](https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.5.4).
You can view, comment on, or merge this pull request online at:

  https://github.com/quicwg/base-drafts/pull/3558

-- Commit Summary --

  * Speak as one with authority
  * No detail here

-- File Changes --

    M draft-ietf-quic-http.md (85)

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/3558.patch
https://github.com/quicwg/base-drafts/pull/3558.diff

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3558

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Mar 2020 21:54:26 -0700

@martinthomson approved this pull request.

> +server presents a certificate that verifiably applies to the host, along with
+proof that it controls the corresponding private key, then a client will accept
+a secured connection to that server as being authoritative for all origins with
+the same scheme and host.
+
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+
+Although HTTP is independent of the transport protocol, the "http" scheme
+associates authority with the ability to receive TCP connections on the
+indicated port of whatever host is identified within the authority component.
+Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the
+authoritative server.  However, protocol extensions such as {{!ALTSVC=RFC7838}}

This seemed incomplete.

```suggestion
authoritative server for a resource identified by an "http" URI.  However, protocol extensions such as {{!ALTSVC=RFC7838}}
```

> +
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+
+Although HTTP is independent of the transport protocol, the "http" scheme
+associates authority with the ability to receive TCP connections on the
+indicated port of whatever host is identified within the authority component.
+Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the
+authoritative server.  However, protocol extensions such as {{!ALTSVC=RFC7838}}
+permit the authoritative server to identify other services which are also
+authoritative and which might be reachable over HTTP/3.
+
+Prior to making requests for an origin whose scheme is not "https," the client

Style question, is this quoting "dialog," in the sense that you put the comma under the quotes?  Either way, this isn't consistent with the remainder of the paragraph.

```suggestion
Prior to making requests for an origin whose scheme is not "https", the client
```

> +secured connection containing the URI's identifying data.
+
+Although HTTP is independent of the transport protocol, the "http" scheme
+associates authority with the ability to receive TCP connections on the
+indicated port of whatever host is identified within the authority component.
+Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the
+authoritative server.  However, protocol extensions such as {{!ALTSVC=RFC7838}}
+permit the authoritative server to identify other services which are also
+authoritative and which might be reachable over HTTP/3.
+
+Prior to making requests for an origin whose scheme is not "https," the client
+MUST ensure the server is willing to serve that scheme.  If the client intends
+to make requests for an origin whose scheme is "http", this means that it MUST
+obtain a valid `http-opportunistic` response for the origin as described in
+{{!RFC8164}} prior to making any such requests.  Other schemes might define
+other mechanisms.

The preceding two paragraphs might be best split off into a subsection as they relate to the "http" scheme.

> +Although HTTP is independent of the transport protocol, the "http" scheme
+associates authority with the ability to receive TCP connections on the
+indicated port of whatever host is identified within the authority component.
+Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to the
+authoritative server.  However, protocol extensions such as {{!ALTSVC=RFC7838}}
+permit the authoritative server to identify other services which are also
+authoritative and which might be reachable over HTTP/3.
+
+Prior to making requests for an origin whose scheme is not "https," the client
+MUST ensure the server is willing to serve that scheme.  If the client intends
+to make requests for an origin whose scheme is "http", this means that it MUST
+obtain a valid `http-opportunistic` response for the origin as described in
+{{!RFC8164}} prior to making any such requests.  Other schemes might define
+other mechanisms.
+
+Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection

```suggestion
Connectivity problems (e.g., firewall blocking UDP) can result in QUIC connection
```

> +authoritative server.  However, protocol extensions such as {{!ALTSVC=RFC7838}}
+permit the authoritative server to identify other services which are also
+authoritative and which might be reachable over HTTP/3.
+
+Prior to making requests for an origin whose scheme is not "https," the client
+MUST ensure the server is willing to serve that scheme.  If the client intends
+to make requests for an origin whose scheme is "http", this means that it MUST
+obtain a valid `http-opportunistic` response for the origin as described in
+{{!RFC8164}} prior to making any such requests.  Other schemes might define
+other mechanisms.
+
+Connectivity problems (e.g. firewall blocking UDP) can result in QUIC connection
+establishment failure; clients SHOULD attempt to use TCP-based versions of HTTP
+in this case.
+
+Servers MAY serve HTTP/3 on any UDP port; an alternative always includes

```suggestion
Servers MAY serve HTTP/3 on any UDP port; an alternative service advertisement always includes
```

Not sure about the use of "advertisement" as that is not in the established nomenclature, but it's hard to distinguish between the service being provided and the declaration of that service being available.

> +an IP address, the client MUST verify that the address appears in the
+subjectAltName of the certificate.

```suggestion
an IP address, the client MUST verify that the address appears as an iPAddress in
the subjectAltName field of the certificate.
```

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3558#pullrequestreview-384399615

---

From: Mike Bishop <[email-masked]>
Date: Tue, 31 Mar 2020 06:48:53 -0700

@MikeBishop pushed 1 commit.

312062018b0596e9a751a7004781598f4059b343  Apply suggestions from code review

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3558/files/9d12af7725d8b44897c17cc174632eb83868340e..312062018b0596e9a751a7004781598f4059b343

---

From: Mike Bishop <[email-masked]>
Date: Tue, 31 Mar 2020 06:58:00 -0700

ee2397b42d7afdd6d8627c0de06c40588b97b007  Rewrap, rearrange

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/3558/files/312062018b0596e9a751a7004781598f4059b343..ee2397b42d7afdd6d8627c0de06c40588b97b007

---

From: ianswett <[email-masked]>
Date: Tue, 31 Mar 2020 12:55:26 -0700

@ianswett approved this pull request.

+The "https" scheme associates authority with the ability of a server to use a
+private key associated with 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 certificate that verifiably applies to the host, along with
+proof that it controls the corresponding private key, then a client will accept
+a secured connection to that server as being authoritative for all origins with
+the same scheme and host.
+
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+
+Connectivity problems (e.g., firewall blocking UDP) can result in QUIC

```suggestion
Connectivity problems (e.g., blocking UDP) can result in QUIC
```
nit: I'd probably remove firewall, since lots of things can block UDP.

> +private key associated with 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 certificate that verifiably applies to the host, along with
+proof that it controls the corresponding private key, then a client will accept
+a secured connection to that server as being authoritative for all origins with
+the same scheme and host.
+
+When an "https" URI is used within a context that calls for access to the
+indicated resource, a client MAY attempt access by resolving the host identifier
+to an IP address, establishing a QUIC connection to that address on the
+indicated port, and sending an HTTP/3 request message to the server over that
+secured connection containing the URI's identifying data.
+
+Connectivity problems (e.g., firewall blocking UDP) can result in QUIC
+connection establishment failure; clients SHOULD attempt to use TCP-based
+versions of HTTP in this case.

Is there any need to mention TCP with TLS since this is in the context of HTTPS requests?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/3558#pullrequestreview-385053922