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

From: Mike Bishop <[email-masked]>
Date: Wed, 01 Apr 2020 07:51:25 -0700

@MikeBishop pushed 1 commit.

c7684769bd36a96eb8cdb3e985b2a5f517f0e49e  Update draft-ietf-quic-http.md

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

---

From: Mike Bishop <[email-masked]>
Date: Wed, 01 Apr 2020 07:55:16 -0700

@MikeBishop commented on this pull request.

> +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.

I think this statement is still sufficient, since any TCP-based version of HTTP will tell you to use TLS for an "https" URL.

-- 
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#discussion_r401679171

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 01 Apr 2020 15:57:02 -0700

@mnot approved this pull request.

LGTM

-- 
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-386005403

---

From: Mike Bishop <[email-masked]>
Date: Thu, 02 Apr 2020 12:12:49 -0700

51587ef5951ec776ef1d547f18dff3b9358842ef  Reorder some things

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

---

From: Kazuho Oku <[email-masked]>
Date: Sun, 05 Apr 2020 03:01:24 -0700

@kazuho approved this pull request.

-- 
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-387801282

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 14 Apr 2020 15:44:43 -0700

@LPardue approved this pull request.

-- 
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-393345998

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 16 Apr 2020 15:05:10 -0700

Are we waiting on a consensus call for this?

-- 
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#issuecomment-614920742

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 16 Apr 2020 15:08:32 -0700

The call has been issued and is running until Saturday UTC. If you have comments, please make them now!

-- 
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#issuecomment-614922026

---

From: Ryan Hamilton <[email-masked]>
Date: Thu, 16 Apr 2020 15:27:52 -0700

Excellent! Can't wait for this to land. (Looks like I need to finish reading my WG email :>)

-- 
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#issuecomment-614929054

---

From: ekr <[email-masked]>
Date: Fri, 17 Apr 2020 12:45:39 -0700

@ekr commented on this pull request.

> @@ -360,30 +399,20 @@ 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.  The client MAY send
-any requests for which the client considers the server authoritative.
-
-An authoritative HTTP/3 endpoint is typically discovered because the client has
-received an Alt-Svc record from the request's origin which nominates the
-endpoint as a valid HTTP Alternative Service for that origin.  As required by
-{{!RFC7838}}, clients MUST check that the nominated server can present a valid
-certificate for the origin before considering it authoritative. Clients MUST NOT
-assume that an HTTP/3 endpoint is authoritative for other origins without an
-explicit signal.
+requests with multiple different URI authority components.  In general, a server
+is considered authoritative for all URIs with the "https" scheme for which the
+hostname in the URI is present in the authenticated certificate provided by the
+server, 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

I fear you need to cite 2818 -- though 6125 is in fact due for revision and that should incorporate 2818.

> -any requests for which the client considers the server authoritative.
-
-An authoritative HTTP/3 endpoint is typically discovered because the client has
-received an Alt-Svc record from the request's origin which nominates the
-endpoint as a valid HTTP Alternative Service for that origin.  As required by
-{{!RFC7838}}, clients MUST check that the nominated server can present a valid
-certificate for the origin before considering it authoritative. Clients MUST NOT
-assume that an HTTP/3 endpoint is authoritative for other origins without an
-explicit signal.
+requests with multiple different URI authority components.  In general, a server
+is considered authoritative for all URIs with the "https" scheme for which the
+hostname in the URI is present in the authenticated certificate provided by the
+server, 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.

Not to be nitpicky but you probably should say that if it doesn't verify it, it must fail.

-- 
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-395727380

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 17 Apr 2020 18:30:16 -0700

@mnot commented on this pull request.

Nope, core - https://github.com/httpwg/http-core/issues/236

-- 
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#discussion_r410538834

---

From: Mike Bishop <[email-masked]>
Date: Mon, 20 Apr 2020 08:04:02 -0700

Merged #3558 into master.

-- 
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#event-3252183954

---

From: Mike Bishop <[email-masked]>
Date: Mon, 20 Apr 2020 08:04:38 -0700

@ekr, I'll get your comments as a separate PR.

-- 
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#issuecomment-616612496