Subject: Focusing our discussion on issues

From: Mark Nottingham <[email-masked]>
Date: Fri, 15 Nov 2013 12:00:27 +0800

We’ve seen a lot of discussion of the proposed response to pervasive monitoring, as well as a number of new participants (welcome!).

The volume (in both senses of the word) of this discussion was perhaps predictable, but it doesn’t help us move forward. It’s very important that people’s positions be heard, but if we don’t transform those opinions into concrete action, we won’t do anything — and again, we had strong agreement that this is is not an acceptable outcome.

Furthermore, if the discussion continues at this volume without resolution, we put our primary deliverable — a better HTTP — at risk, which is also unacceptable.

So, while the last couple of days have been relatively open-season (i.e., I’ve only called people out when they drift towards ad hominem or other destructive patterns), I’m going to be reminding people to stay on-topic for *this* working group’s charter moving forward.

In particular, I’ve started to open new issues to track where I think our discussion needs to go:

* HTTP2 and http:// URIs on the "open” internet <https://github.com/http2/http2-spec/issues/314> — this is the most relevant issue to our current discussion. You can move it forward by proposing specific text for the spec.

* Opportunistic Encryption <https://github.com/http2/http2-spec/issues/315> — this issue is on hold for the moment, but not closed.

* “Explicit” Proxies <https://github.com/http2/http2-spec/issues/316> — several people have expressed interest in this, and we’re looking for use cases and proposals to flesh it out. Note that we’re likely to have more proxy-related issues soon.

* TLS man-in-the-middle <https://github.com/http2/http2-spec/issues/317> — this is a liaison issue; i.e., if someone else has a solution to this problem that we think will improve HTTP, we can reference or even require its use.

* TLS profile for HTTP <https://github.com/http2/http2-spec/issues/318> — as discussed during perpass and elsewhere, we can improve how HTTP uses TLS, regarding cipher suites, extensions, etc. This is listed as a liaison issue for the moment, since there’s a larger discussion around use of TLS in the IETF.

* User Experience for TLS <https://github.com/http2/http2-spec/issues/319> — another liaison issue about how different aspects of TLS are presented to the user.

* Orphaning http:// URIs <https://github.com/http2/http2-spec/issues/320> — as brought up by Julian, we need to figure out how important this is, and what an appropriate response is.

Focusing discussion on specific issues will help us move forward, rather than in circles. It’s doubtless that we’ll add more issues as we go on, as well as refine the ones that I’ve sketched in. 

While anyone can add an issue to the list, I’m asking people to exercise restraint; if an issue looks like advocacy, is a duplicate, or doesn’t help us converge on consensus, I won’t hesitate to delete it. I strongly suggest that new issues be discussed on the list first (flagging the proposal with a subject that begins with “Proposed issue:”). 

Finally, while we have the ability to comment on issues, I will remind people that substantial discussion needs to happen on *this* list, not there. I.e., if you have a question about the scope or intent of an issue, it’s fine to ask it in a comment there; if you want to state an opinion or provide facts, it needs to be over here.

Note also that the “liaison issues” are fundamentally about work that happens SOMEWHERE ELSE — we might talk about how much we like that work, whether we’ll use it, etc., but the actual work doesn’t happen here. I know some people don’t like it when we say something isn’t our problem, but doing so helps us actually get the work for which we’re responsible done.

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Fri, 15 Nov 2013 08:45:13 +0000

In message <[email-masked]>, Mark Nottingham wri
tes:

>We've seen a lot of discussion of the proposed response to pervasive 
>monitoring, as well as a number of new participants (welcome!).
>
>The volume (in both senses of the word) of this discussion was perhaps 
>predictable, but it doesn't help us move forward.

First, I think everybody needs to step away from the keyboard and
re-read the chapter named "Second Systems Syndrome" in The Mythical
Man-Month.

By all means read all of the book while you're at it, and don't
worry if it will take you some days to buy the book first:  It will
save you much more time later in life.

Presently people are trying to make HTTP/2.0 resolve all their
current grieveances, be they related to HTTP or not, by cramming
their particular agenda into the proposed protocol.

That is not going to give us a good new protocol, certainly not
soon and likely not ever.

I motion that we call a timeout while people read up on their
classics, and propose that the WG:

A)      Define a successor to HTTP/1.1, which moves HTTP objects
	across *any* transparent byte-pipe with better performance
	than HTTP/1.1.

B)	If sensible, define an upgrade mechanisem from HTTP/1.1 to
	the new protocol, that reuse the underlying byte-pipe.

C)      Decide that discussions about selection of, and mapping of
	URI scheme to, byte-pipe carriers, is unnecessary and
	unproductive.

In re A:  Emphasis on *any*, if we can't beat HTTP/1.1 on *any*
	  connection, we're not doing a good enough job.

In re B:  This has proven much harder in terms of protocol-trickery,
	  port 80 is a lot less of transparent byte-pipe in
	  practice than some of us expected and it costs us a
	  performance hit during startup.
	  
In re C:  If we design HTTP/2.0 to be encryption agonistic, it
	  will not go down when any particular encryption protocol
	  policy sinks.  There is no point and no benefit in tying
	  ourselves to the mast

Thanks,

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 15 Nov 2013 09:51:10 +0100

+1 to all of this.

> 	  policy sinks.  There is no point and no benefit in tying

<green/>bytes GmbH
Hafenweg 16, 48155 Münster, Germany
Phone: +49 251 2807760. Amtsgericht Münster: HRB5782

---

From: Michael Sweet <[email-masked]>
Date: Fri, 15 Nov 2013 10:36:17 -0500

+1.

FWIW, there exists (and is widely implemented, at least with CUPS and printers) the HTTP Upgrade to TLS mechanism (RFC 2817 - http://tools.ietf.org/html/rfc2817) that allows a client, server, or proxy to force encryption of that connection.  This isn’t a replacement for end-to-end TLS (https://) but perhaps points to a better way for HTTP/2.0 to interoperate with proxies and solve item B below.

To summarize, a HTTP/2.0 capable user agent wanting to display the contents of “http://www.example.com/index.html” can include an Upgrade header in its initial HTTP/1.1 request, for example:

    GET /index.html HTTP/1.1
    Host: www.example.com
    Upgrade: HTTP/2.0

A proxy that receives this does not (or at least is not supposed to…) forward the Upgrade header, and can either respond with 101 Switching Protocols if it supports HTTP/2.0 or ignore the header and return a HTTP/1.1 response (cached or otherwise).

Similarly, proxies that support HTTP/2.0 could include their own Upgrade header when sending a request to the server or next proxy, doing the same upgrade dance.

The advantage here is that we always start with HTTP/1.1 (compatibility with proxies) but opportunistically upgrade to HTTP/2.0 when supported.

The same mechanism can be used for https://, and may in fact be needed given that we now know that MITM https:// proxies are widely deployed and could likely have the same limitations as http:// proxies.

Thoughts?

> 	  policy sinks.  There is no point and no benefit in tying

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Fri, 15 Nov 2013 10:54:44 -0500

Also I should include a reference to the definition of the Upgrade header, which has a specific example for a hypothetical HTTP/2.0:

    http://tools.ietf.org/html/rfc2616#section-14.42

and the updated version here:

    http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-24#page-56

---

From: Roland Zink <[email-masked]>
Date: Fri, 15 Nov 2013 17:34:30 +0100

> Similarly, proxies that support HTTP/2.0 could include their own Upgrade header when sending a request to the server or next proxy, doing the same upgrade dance.
In the current HTTP/2 draft the upgrade is used to upgrade from HTTP/1 
to HTTP/2, but still in text form. Your proposal is to use upgrade to 
TLS and use ALPN to go to HTTP/2 over TLS? This seems fine to me. The 
question I asked already earlier is the goal to have an end to end 
(whatever this means) connection to tunnel through the internet or is 
the goal to use TLS to the next hop.
> The advantage here is that we always start with HTTP/1.1 (compatibility with proxies) but opportunistically upgrade to HTTP/2.0 when supported.
I think there should also be a way to directly do HTTP/2.

Regards,
Roland

---

From: Michael Sweet <[email-masked]>
Date: Fri, 15 Nov 2013 12:00:56 -0500

Roland,

On Nov 15, 2013, at 11:34 AM, Roland Zink <[email-masked]> wrote:
>> ...
> In the current HTTP/2 draft the upgrade is used to upgrade from HTTP/1 to HTTP/2, but still in text form. Your proposal is to use upgrade to TLS and use ALPN to go to HTTP/2 over TLS? 

No - although that would be a convenient way to upgrade to TLS and HTTP/2.0 at the same time, it specifically only applies to the current hop and may not provide end-to-end encryption.

My main proposal is that upgrade to HTTP/2.0 can be accomplished through the existing HTTP/1.1 Upgrade mechanism which is already compatible with HTTP/1.1 proxies.  This will allow for reliable clear text HTTP/2.0 operation for http:// URIs while also potentially solving the MITM https:// proxy issues as well.

> This seems fine to me. The question I asked already earlier is the goal to have an end to end (whatever this means) connection to tunnel through the internet or is the goal to use TLS to the next hop.

I think for https:// you expect the connection encryption to be end-to-end, although when MITM proxies are involved the contents will not stay encrypted all of the way to the other end.

> I think there should also be a way to directly do HTTP/2.

So long as we are reusing HTTP/1.1’s port 80, I don’t see how we can do that for clear text HTTP/2.0, and honestly if your first request has to be HTTP/1.1 with the Upgrade: header, I don’t see that as a major overhead.

---

From: Roberto Peon <[email-masked]>
Date: Fri, 15 Nov 2013 09:08:54 -0800

The issue here is the poorly implemented proxies which don't conform to the
spec w.r.t upgrade, connect, etc. since they didn't bother to deal with
these corner cases.

Upgrade within an encrypted channel, however, would work though it buys you
nothing but additional complexity as compared to ALPN at that point.

-=R
On Nov 15, 2013 9:02 AM, "Michael Sweet" <[email-masked]> wrote:

> >> Similarly, proxies that support HTTP/2.0 could include their own
> Upgrade header when sending a request to the server or next proxy, doing
> the same upgrade dance.
> to HTTP/2, but still in text form. Your proposal is to use upgrade to TLS
> and use ALPN to go to HTTP/2 over TLS?
>
> No - although that would be a convenient way to upgrade to TLS and
> HTTP/2.0 at the same time, it specifically only applies to the current hop
> and may not provide end-to-end encryption.
>
> My main proposal is that upgrade to HTTP/2.0 can be accomplished through
> the existing HTTP/1.1 Upgrade mechanism which is already compatible with
> HTTP/1.1 proxies.  This will allow for reliable clear text HTTP/2.0
> operation for http:// URIs while also potentially solving the MITM
> https:// proxy issues as well.
>
> > This seems fine to me. The question I asked already earlier is the goal
> to have an end to end (whatever this means) connection to tunnel through
> the internet or is the goal to use TLS to the next hop.
>
> I think for https:// you expect the connection encryption to be
> end-to-end, although when MITM proxies are involved the contents will not
> stay encrypted all of the way to the other end.
>
> >> The advantage here is that we always start with HTTP/1.1 (compatibility
> with proxies) but opportunistically upgrade to HTTP/2.0 when supported.
> So long as we are reusing HTTP/1.1’s port 80, I don’t see how we can do
> that for clear text HTTP/2.0, and honestly if your first request has to be
> HTTP/1.1 with the Upgrade: header, I don’t see that as a major overhead.
>
> >
> > Regards,
> > Roland
> >> The same mechanism can be used for https://, and may in fact be needed
> given that we now know that MITM https:// proxies are widely deployed and
> could likely have the same limitations as http:// proxies.
> >> Thoughts?
> >>
> >>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 15 Nov 2013 14:35:14 -0500

And to answer a common offline question I’ve been getting, this is different from the current HTTP/2.0 draft in that the client does not send a Connection: Upgrade header, but instead relies on the server to do so in its response (server-initiated upgrade vs. client-initiated upgrade).  That at least gives server operators a better chance to turn off unencrypted HTTP/2.0 vs. relying on the client to know when it is “safe” to do so...

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 18 Nov 2013 12:25:05 +1100

Michael,

We've discussed Upgrade extensively. While there is some implementer interest in it, there are also a number of issues. Summarising from memory:

 - A number of intermediaries do not strip hop-by-hop headers correctly, leading to failure
 - When the upgrade fails, it can do so in an indeterminate state, leading to delay or (worse) security vulnerabilities
 - Feedback from implementers is that upgrade can be difficult to implement
 - While the upgrade is in progress, the connection is unusable for other requests

We haven't given up on Upgrade yet, but enough implementers have expressed doubt about it that we're also looking at other mechanisms (e.g., Alternate-Services, which includes an end-to-end response header, and could be extended to include DNS discovery, which of course has its own problems).

However, this is all orthogonal to the issues at hand -- you're (re-)proposing a specific mechanism for optimistic encryption, when the more immediate question is whether we should specify one, and if we do, whether it will get deployed.

Cheers,

---

From: Michael Sweet <[email-masked]>
Date: Sun, 17 Nov 2013 23:39:34 -0500

Mark,

I'm actually not referring to TLS upgrade (which only affects the current hop) but adjusting how a client does a clear text upgrade to HTTP/2.0.  By having the client wait to see an Upgrade: header from the other end, we might eliminate some of the common proxy incompatibilities of the current (client initiates on first request) mechanism.

As for difficulties in implementation, I do know that the initial generation of printers supporting RFC 2817 had some issues, but there are some clear guidelines that we can provide to avoid some of the edge cases (mainly, always have the client send an OPTIONS request to do the upgrade instead of a general request...)

>>>> 	  policy sinks.  There is no point and no benefit in tying

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair