Subject: Re: [quicwg/base-drafts] Expand connection management text (#1024)

From: Martin Thomson <[email-masked]>
Date: Mon, 01 Jan 2018 14:56:36 -0800

martinthomson approved this pull request.

These changes address my concerns.  I have some new ones.  These are minor.

> @@ -182,6 +190,24 @@ itself as "hq-09-rickroll". Note that any label MUST conform to the "token"
 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are encouraged to
 coordinate their experiments on the [email-masked] mailing list.
 
+## Connection Reuse
+
+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/QUIC 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

should we use "server" here rather than "endpoint"?

> @@ -182,6 +190,24 @@ itself as "hq-09-rickroll". Note that any label MUST conform to the "token"
 syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are encouraged to
 coordinate their experiments on the [email-masked] mailing list.
 
+## Connection Reuse
+
+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/QUIC 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 SHOULD
+NOT assume that an HTTP/QUIC endpoint is authoritative for other origins without

"SHOULD NOT assume"?  "cannot" or "MUST NOT" perhaps

-- 
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/1024#pullrequestreview-86071088

---

From: Mike Bishop <[email-masked]>
Date: Tue, 02 Jan 2018 18:24:30 +0000 (UTC)

MikeBishop commented on this pull request.

+## Connection Reuse
+

What led me to that wording is that the same server might offer both TCP(HTTP/2) and UDP(QUIC) endpoints, so we're not necessarily discovering a new server.  It's ultimately an IP:port that we're connecting to, and I think "endpoint" is a more accurate term there.  Alternate terms for that concept welcome.

-- 
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/1024#discussion_r159284270

---

From: Mike Bishop <[email-masked]>
Date: Tue, 02 Jan 2018 18:25:39 +0000 (UTC)

+## Connection Reuse
+

Yeah, I don't remember what my logic was for that one.  Probably trying to dance around the ORIGIN-style trust model.  Either is fine.

-- 
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/1024#discussion_r159284506

---

From: Mike Bishop <[email-masked]>
Date: Wed, 03 Jan 2018 16:29:04 -0800

@MikeBishop pushed 1 commit.

4909203  MUST NOT assume

-- 
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/quicwg/base-drafts/pull/1024/files/bf482f1209fb2652e8b73580ee18cfb54df5dfea..490920335015ffce5074aca494779f6b0f660d99

---

From: Mike Bishop <[email-masked]>
Date: Thu, 04 Jan 2018 09:15:44 -0800

Merged #1024.

-- 
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/1024#event-1409939958

---

From: MikkelFJ <[email-masked]>
Date: Wed, 31 Jan 2018 11:20:52 +0000 (UTC)

@MikeBishop I'm not that familiar with SNI, but if it is required, will it work in scenarios where HTTP is not using name based addressing, such as in a RPC server cluster where only IP addresses are used for identification?

-- 
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/1024#issuecomment-361902970

---

From: Mike Bishop <[email-masked]>
Date: Wed, 31 Jan 2018 11:38:11 -0800

That's a good question -- the HTTP/2 language is 

> The TLS implementation MUST support the Server Name Indication (SNI) [TLS-EXT] extension to TLS.  HTTP/2 clients MUST indicate the target domain name when negotiating TLS.

I assume that's currently working for you...?

-- 
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/1024#issuecomment-362046179

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 12:50:57 -0800

That won't work, because SNI can't technically hold a IP literal.  However, it is common for clients to accept IP addresses in subjectAltName.  The only option there - if you care about compliance - is to make up an SNI (use the named from the reverse DNS tree perhaps) and to have the server effectively ignore the SNI and provide the IP-based certificate.  Practically speaking, if you don't have a name, then omitting SNI is probably fine.

Yet another reminder that this ecosystem is full of landmines.

-- 
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/1024#issuecomment-362066256

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 31 Jan 2018 21:00:24 +0000 (UTC)

By omission, do you mean an empty sni extension value, or no extension at all?

Http/Quic sounds looser than Http/2

"The Server Name Indication (SNI) extension [RFC6066] MUST be included in the TLS handshake."

-- 
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/1024#issuecomment-362068823

---

From: Martin Thomson <[email-masked]>
Date: Wed, 31 Jan 2018 21:03:25 +0000 (UTC)

Yes, and that isn't accurate - it implies that the server is also bound by the requirement - which is technically allowed for servers, but the extension is rarely sent (it makes no sense for a server to send it).

-- 
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/1024#issuecomment-362069593