Re: Focusing our discussion on issues

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...)


On Nov 17, 2013, at 8:25 PM, Mark Nottingham <mnot@mnot.net> wrote:

> 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,
> 
> 
> 
> On 16/11/2013, at 2:54 AM, Michael Sweet <msweet@apple.com> wrote:
> 
>> 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
>> 
>> 
>> On Nov 15, 2013, at 10:36 AM, Michael Sweet <msweet@apple.com> wrote:
>> 
>>> +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?
>>> 
>>> 
>>> 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
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Monday, 18 November 2013 04:39:51 UTC