Re: Focusing our discussion on issues

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" <msweet@apple.com> wrote:

> Roland,
>
> On Nov 15, 2013, at 11:34 AM, Roland Zink <roland@zinks.de> 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.
> > 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.
>
> >> 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.
>
> 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?
> >>
> >>
> >> On Nov 15, 2013, at 3:45 AM, Poul-Henning Kamp <phk@phk.freebsd.dk>
> wrote:
> >>> In message <242B6E8E-BC39-44A0-8668-EEBDEBE4A416@mnot.net>, 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
> >>> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> >>> FreeBSD committer       | BSD since 4.3-tahoe
> >>> Never attribute to malice what can adequately be explained by
> incompetence.
> >>>
> >> _______________________________________________________________
> >> Michael Sweet, Senior Printing System Engineer, PWG Chair
> >>
> >>
> >
> >
>
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
>