Subject: [quicwg/base-drafts] HTTP-31: Requirement to use ALPN with HTTP/3 (#4208)

From: Magnus Westerlund <[email-masked]>
Date: Wed, 14 Oct 2020 06:08:16 -0700

Section 3.2:

"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 on the indicated port, and sending an HTTP/3 request message targeting the URI to the server over that secured connection."

draft-ietf-quic-tls states in Section 8.1:

 "Unless another mechanism is used for agreeing on an application protocol, endpoints MUST use ALPN for this purpose."

Looking at Section 3.2 with Section 3.1 deleted I think there is an important aspect missing which is expressed in first sentence of Section 3.1:

"HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc." 

In Section 3.3:

"QUIC connections are established as described in [QUIC-TRANSPORT]. During connection establishment, HTTP/3 support is indicated by selecting the ALPN token "h3" in the TLS handshake. Support for other application-layer protocols MAY be offered in the same handshake."

So what I interpret is that the inclusion of the "h3" ALPN token will be required in the clients messages when establishing an QUIC connection with the intention of communicating using HTTP/3 according to this specification.  

So I think there are two changes needed here. First that there needs to be a first paragraph in Section 3.2 to state that HTTP/3 uses "h3" as token in ALPN and Alt-Svc as a lead in, secondly that the sentence first referenced above needs to state that ALPN = "h3" will be given in the QUIC-TLS handshake. 

If I understand this correctly, a QUIC connection that has been established using "h3" ALPN token, i.e. client tells it interested in this application and where the server choice that token in the handshake will be using HTTP/3 according to this specification. It is possible for other ALPN tokens to be application foo using HTTP/3. Finally do I interpret things correctly that "h3" is not strictly required but then both client and server need to know that yes, this connection establishment is for the purpose of HTTP/3? 

-- 
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/issues/4208

---

From: Mike Bishop <[email-masked]>
Date: Wed, 14 Oct 2020 07:22:26 -0700

If some other mechanism is used for agreeing on protocol, ALPN can be omitted, yes.

I'm not convinced that the first paragraph of 3.[2->1] is the appropriate place to put the token statement; the section is about discovering an HTTP/3 endpoint given a URL, and the definition of the ALPN token is incidental there.  I've added the token to 3.[2->1] in the paragraph about the connection; see what you think.

-- 
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/issues/4208#issuecomment-708436761

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Oct 2020 03:02:03 -0700

I think the proposed text does clarify the issue and makes the default and alternative clear. So this resolves my issue. 

-- 
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/issues/4208#issuecomment-709064416

---

From: Lars Eggert <[email-masked]>
Date: Thu, 15 Oct 2020 04:21:14 -0700

Based on #4211, labeling this as "editorial"

-- 
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/issues/4208#issuecomment-709213661

---

From: Mike Bishop <[email-masked]>
Date: Thu, 15 Oct 2020 11:42:19 -0700

Closed #4208 via #4211.

-- 
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/issues/4208#event-3883060538