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

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Dec 2017 19:48:08 +0000 (UTC)

(Fixes #940, #794)

Adds the requirement for TLS as the handshake protocol (agreed in Chicago, but never added to draft) and discusses connection reuse aspects we've probably all been assuming but never wrote down.

I feel like we might still need a stronger text than "QUIC as the underlying transport," since HTTP/QUIC technically has a dependency on the ability for the client to initiate bidirectional streams and the server to initiate unidirectional streams.  There's no guarantee that arbitrary QUIC versions would include that, so we perhaps should state it.
You can view, comment on, or merge this pull request online at:

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

-- Commit Summary --

  * Expand connection management text (Fixes #940, #794)

-- File Changes --

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

-- Patch Links --

https://github.com/quicwg/base-drafts/pull/1024.patch
https://github.com/quicwg/base-drafts/pull/1024.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/1024

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Dec 2017 22:45:41 +0000 (UTC)

martinthomson commented on this pull request.

This looks OK, but I think that you need to restructure the bit about authority and Alt-Svc.

> @@ -182,6 +189,22 @@ 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.
+
+This typically means that the client has received an Alt-Svc record from the
+request's origin in question which nominates the server endpoint as a valid HTTP

This is potentially misleading.  Alt-Svc doesn't form the basis for authority.  I understand the intent here is to say that you don't get here without Alt-Svc, but the "This" in this sentence is immediately after the bit about authority.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Dec 2017 23:30:18 +0000 (UTC)

MikeBishop commented on this pull request.

+## Connection Reuse
+

"This" does in fact refer to considering the server authoritative, so you're reading it correctly.  RFC 7838 does say that Alt-Svc provides authority.

> Alternative services are considered authoritative for an origin's resources....

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 18 Dec 2017 15:41:46 -0800

+## Connection Reuse
+

I think that we're talking past each other.  The alternative is not authoritative because of Alt-Svc, that authority derives from the certificate.  This text implies that it derives from Alt-Svc, which is dangerously misleading.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Dec 2017 15:49:38 -0800

+## Connection Reuse
+

Perhaps.  I think this is an area that's in flux right now -- example.com:443 is authoritative for https://example.com/, but the certificate validates that you're actually talking to example.com:443.  Under any previous RFC, a server isn't authoritative simply because it has the certificate.

Alt-Svc allows an authoritative server to say that otherguy.org:8080 is co-authoritative with it.  You still need to validate the cert to verify that you've successfully reached the authoritative alternative, but it *is* the Alt-Svc delegation that makes it authoritative.  The certificate simply proves identity when connecting to that authoritative endpoint.

ORIGIN makes the stronger statement that a server can be authoritative *simply* because it has the certificate, if the client chooses to play by those new rules.  That's a new assertion in RFC [TBD], but not something contained in any existing RFC that I'm aware of.

I'll add some text saying that, as required by RFC 7838, the client MUST ensure that the certificate is valid for the origin being requested.

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 18 Dec 2017 23:54:39 +0000 (UTC)

@MikeBishop pushed 1 commit.

66bd92c  Require cert validation

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

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 19 Dec 2017 20:56:12 +0000 (UTC)

LPardue commented on this pull request.

Overall I think this does address the issues indicated. Some remaining questions that maybe don't need to be answered here:

* are there any special considerations for connection reuse for 0-RTT or 1-RTT?
* RFC7540 also describes connection reuse in terms of the CONNECT method and Proxies, is that still applicable?

>  connection establishment, HTTP/QUIC support is indicated by selecting the ALPN
-token "hq" in the crypto handshake.
+token "hq" in the crypto handshake.  Support for other application-layer

nit: s/crypto/cryptographic to better align with Transport doc terminology. Seems like an opportunity to fix it up while in this area.

> @@ -147,11 +149,16 @@ Origins SHOULD list only versions which are supported by the alternative, but
 MAY omit supported versions for any reason.

-# Connection Establishment {#connection-establishment}
+## Connection Establishment {#connection-establishment}
+
+HTTP/QUIC relies on QUIC as the underlying transport.  The QUIC version being
+used MUST use TLS version 1.3 or greater as its handshake protocol.  The Server
+Name Indication extension {{!RFC6066}} MUST be included in the TLS handshake.

I missed the SNI reference because the acronym was not used, may help to add _(SNI)_.

RFC7540 also says clients MUST indicate target domain when negotiating TLS, is that requirement inherited here?

> @@ -182,6 +189,24 @@ itself as "hq-09-rickroll". Note that any label MUST conform to the "token"
 
+## 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 validate that the nominated server can present a
+validated certificate for the origin before considering it authoritative.

"validate a validated certificate" sounds odd.

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

---

From: Mike Bishop <[email-masked]>
Date: Sat, 23 Dec 2017 21:19:27 +0000 (UTC)

bf482f1  Lucas's feedback

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

---

From: Mike Bishop <[email-masked]>
Date: Sat, 23 Dec 2017 13:21:18 -0800

I tried a couple of different wordings with the requirement on what to include in SNI, but nothing felt right.  (Particularly in light of the Alt-Svc SNI draft, which suggests that the SNI might be something to which you don't actually intend to direct resources.)  I ultimately decided to leave it at MUST use the extension and MUST make sure you've seen a valid cert for an origin before using the connection for it.  If those two are related or not is a case-by-case choice by the implementation.

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

---

From: Mike Bishop <[email-masked]>
Date: Sat, 23 Dec 2017 21:22:18 +0000 (UTC)

How about "TLS," since I've already said we're bound to that anyway?  ;-)

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

---

From: Mike Bishop <[email-masked]>
Date: Sat, 23 Dec 2017 21:23:49 +0000 (UTC)

Planning to merge soonish, unless @martinthomson is still unhappy with the authority text or someone else squawks.

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