Subject: [Doh] How to start HTTP/2?

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Jan 2018 16:02:46 +0100

RFC 7540 specifies several ways to start HTTP/2 over a TCP connection
(section 3), such as upgrade from HTTP/1, or starting directly HTTP/2
if you know the server accepts it. Which one should be used by DoH
clients and servers? Section 7 of draft-ietf-doh-dns-over-https-02
seems silent about it.

Note that this interacts with the discussion about whether HTTP/2
support is SHOULD or MUST.

For the server:

1) accepts all RFC 7540 methods?
2) accepts only "immediately receives HTTP/2 frames"?

For the client?

1) try all RFC 7540 methods? In which order?
2) try only "immediately sends HTTP/2 frames"? (If HTTP/2 support is a
MUST, it makes sense)

Note that some clients are currently limited. I don't think you can
immediately send HTTP/2 frames with curl, for instance.

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 16 Jan 2018 16:12:39 +0100 (CET)

On Tue, 16 Jan 2018, Stephane Bortzmeyer wrote:

> (section 3), such as upgrade from HTTP/1, or starting directly HTTP/2 if you 
> know the server accepts it. Which one should be used by DoH clients and 
> servers? Section 7 of draft-ietf-doh-dns-over-https-02 seems silent about 
> it.

If you stick to HTTPS (which the spec says we must in section 4) then there's 
only one way: negotiate HTTP version with ALPN. It also happens to be the 
easiest way for clients IMHO.

> immediately send HTTP/2 frames with curl, for instance.

curl can actually do the three common ways:

1. negotiate HTTP/2 with HTTPS

2. upgrade from h1 using clear-text HTTP (but upgrade to HTTP/2 on a POST is 
not very supported by servers)

3. do "prior knowledge" HTTP/2 over clear-text HTTP

-- 

  / daniel.haxx.se

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Jan 2018 16:12:53 +0100

On Tue, Jan 16, 2018 at 04:02:46PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 

> immediately send HTTP/2 frames with curl, for instance.

Bad example, curl --http2-prior-knowledge (always read the doc, then
read it again).

---

From: Patrick McManus <[email-masked]>
Date: Tue, 16 Jan 2018 10:16:58 -0500

> clients and servers? Section 7 of draft-ietf-doh-dns-over-https-02
any valid 7540 mechanism is acceptable to DoH. however note that the
upgrade header specified by 3.2 of 7540 only applies to "http" schemed uris
and DoH requires "https" schemed uris. So as a practical matter you're
going to use ALPN with TLS though you would be allowed to use "prior
knowledge".. but if h2 is not a DoH MUST then the presence of DoH itself
doesn't constitute prior knowledge. (caching or configuration might
qualify).

> support is SHOULD or MUST.
we reached consensus on that being SHOULD.. also its "h2 or its successors"
and I think that nit is important here..

> 1) accepts all RFC 7540 methods?

DoH doesn't constrain the server here. Indeed the server can serve more
than DoH simultaneously.

> 2) accepts only "immediately receives HTTP/2 frames"?
by which you mean ignore ALPN? That seems like a bad plan.

> 2) try only "immediately sends HTTP/2 frames"? (If HTTP/2 support is a
again, I don't see a reason that DoH would particularly influence the
connection establishment choices.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 16 Jan 2018 16:21:45 +0100

On Tue, Jan 16, 2018 at 04:12:39PM +0100,
 Daniel Stenberg <[email-masked]> wrote 
 a message of 27 lines which said:

> If you stick to HTTPS (which the spec says we must in section 4)
> then there's only one way: negotiate HTTP version with ALPN. It also
> happens to be the easiest way for clients IMHO.

OK, but could it be better to say explicitely "Servers and clients
MUST start HTTP/2 using the ALPN extension of TLS, as specified in RFC
7540, section 3.3"?

(Then, what a server should do if the client did not use ALPN? Start
HTTP/2 anyway, because of the robustness principle?)

---

From: Patrick McManus <[email-masked]>
Date: Tue, 16 Jan 2018 10:29:54 -0500

> MUST start HTTP/2 using the ALPN extension of TLS, as specified in RFC
imo, no.. a] h2 isn't required.. and even where its a should it is h2 or
its successors. successors might do it differently.

b] a large point of using h2 as a substrate is that you just reuse h2 and
don't need to restate things (possibly incorrectly by accident)

c] h2 can be extended in ways that could conflict with that language. I
don't see the value in forcing those extensions to be aware enough to also
extend DoH.

> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 16 Jan 2018 16:30:07 +0100 (CET)

On Tue, 16 Jan 2018, Stephane Bortzmeyer wrote:

> OK, but could it be better to say explicitely "Servers and clients MUST 
> start HTTP/2 using the ALPN extension of TLS, as specified in RFC 7540, 
> section 3.3"?

It probably could, but as that's exactly what doing HTTP/2 over HTTPS means I 
considered that implied.

> (Then, what a server should do if the client did not use ALPN? Start HTTP/2 
> anyway, because of the robustness principle?)

If you want HTTP/2 over HTTPS, you need to use ALPN. An HTTPS server that 
doesn't do ALPN can't speak HTTP/2 as defined in RFC7540.

-- 

  / daniel.haxx.se

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Jan 2018 10:12:01 +1100

What Daniel said.  We're really only targetting HTTPS here, and HTTPS
means TLS and ALPN when it comes to HTTP/2.

Also, as a practical matter, HTTP/2 over TLS with ALPN is the only
configuration that is widely deployed and available.  curl is somewhat
exceptional here in its promiscuity, but that's a core feature of
curl.

On Wed, Jan 17, 2018 at 2:30 AM, Daniel Stenberg <[email-masked]> wrote:
> It probably could, but as that's exactly what doing HTTP/2 over HTTPS means
> I considered that implied.
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Jan 2018 09:18:23 +0100

On Tue, Jan 16, 2018 at 10:29:54AM -0500,
 Patrick McManus <[email-masked]> wrote 

> its successors. successors might do it differently.
...
> don't see the value in forcing those extensions to be aware enough to also

OK, I understand. But can it raise interoperability issues? If a
client tries one way and the server does not understand it, won't it
mean at least a delay in noticing and fixing the problem?

Martin Thomson said it is not a problem because everyone uses TLS and
ALPN, anyway. But it contradicts what you say about the possibility of
future changes using other techniques.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 17 Jan 2018 10:03:42 -0500

> future changes using other techniques.

for h2, everyone does use TLS/ALPN/TCP-443 for the base case.. but if
you're using alt-svc then the host and port are resolved differently. DoH
can use Alt-Svc but DoH (rightly) doesn't reference it. Alt-Svc is an h2
extension (rfc 7838)

hq (HTTP on Quic - an IETF successor to h2) will be a bit more
complicated.. not only will you need TLS and ALPN but you'll need Alt-Svc
(or something like it) for even the base case as TCP/443 isn't going to
work. Again, referencing the details in doh doesn't help a lot beyond
saying "MUST connect via https and SHOULD use h2 or its successors".

One of the reasons this can't be a MUST is actually ensuring a >= h2 path
is nigh impossible given all of abstractions in infrastructure. Its not
meant to say you should always fail the connection if it is not made over
H2, just
a] make sure your implementation offers and tries to use >= h2 in the usual
ways
b] understand that if you're not using >= h2 there are serious scaling and
performance issues

If this can be expressed as non-normative advice in a sentence or three
that would be ok by me but in general I think this is what using https as a
substrate means.