Re: A proposal

Hi

------ Original Message ------
From: "Roberto Peon" <grmocg@gmail.com>
To: "Adrien de Croy" <adrien@qbik.com>
Cc: "James M Snell" <jasnell@gmail.com>; "ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
Sent: 18/11/2013 10:01:13 a.m.
Subject: Re: A proposal
>Folks won't rewrite for a new scheme until it is supported by all 
>clients, and that won't happen until there is sufficient (and by that I 
>mean overwhelming) demand for such.
>... thus, a new scheme won't work as it is firmly in chicken-and-egg 
>territory, even in intranets :/
that's basically what I was saying. I don't think a new scheme will 
work, and I don't think we need one.

>
>Happy eyeballs-like strategies either introduce latency or introduce 
>complexity, and sometimes both. For fun: which connection do you send 
>any particular request down?
Chrome already makes many opportunistic connections that never get a 
request.

how woudl making some over 100 be any different.
If you get a connection on both, use port 100 for http/2.0 and drop the 
80 one, and remember that.

We could also use DNS (e.g. new record, or new SRV record) to make this 
more deterministic.

>
>HTTP/2 over :443 works just fine even with MITMs, as they will need to 
>terminate the TLS channel, which means that they can refuse to 
>negotiate HTTP/2 during the ALPN negotiation.

Yes.  I'm saying the more MITMs go out there that don't support 2.0, the 
less likely you will get 2.0.  It will be down-graded to 1.1 over TLS.  
So claims about deployability of 2.0 over 443 I think should not just be 
swallowed without question.

Adrien

>
>-=R
>
>
>On Sun, Nov 17, 2013 at 12:47 PM, Adrien de Croy <adrien@qbik.com> 
>wrote:
>>
>>compared with the existing proposed methods of determining whether 
>>http/2.0 is available or not, including:
>>
>>* some new DNS record
>>* upgrade dance
>>
>>actually testing for connectivity on a new port is miles easier. A 
>>client can send 2 SYN packets at the same time.  Connectivity on a new 
>>reserved/allocated port such as 100 would be a fairly clear indication 
>>that we are dealing with http/2.0
>>
>>Keep in mind, with a MITM, you can't presume that http/2.0 is 
>>deployable as currently proposed over 443 with NPN or ALPN.  In fact I 
>>believe that due to the growth of MITM, the deployabilty of anything 
>>other than http/1.1 over TLS is reducing.
>>
>>Crypto or not could then be negotiated on the connection.  A server 
>>can offer it, and a client can defer to a user as to whether the user 
>>is prepared to go unencrypted or not.  Agents so configured can make 
>>that choice already, so that plaintext deployment is possible with low 
>>pain level in situations that require it.
>>
>>No need or desire for a new scheme (and face it, no-one is going to 
>>re-write their web apps for a new scheme to send people down the 
>>garden path by advertising a new scheme which the client cannot 
>>access).
>>
>>Adrien
>>
>>
>>------ Original Message ------
>>From: "James M Snell" <jasnell@gmail.com>
>>To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>>Sent: 18/11/2013 7:08:04 a.m.
>>Subject: A proposal
>>>The volume on the other threads on the security subject is causing 
>>>far too much noise. I have a proposal that offers a compromise 
>>>approach. I posted about this partially in one of the threads but I'm 
>>>afraid it got lost in the noise. Others have touched on the same 
>>>basic idea:
>>>
>>>1. By default, assign plain text http/2 to a new port.
>>>2. Document that plaintext http/2 can be sent over port 80 but 
>>>document the various possible issues with reliability.
>>>3. Strongly recommend that http/2 be sent over TLS instead of 
>>>plaintext.
>>>4. Establish a new http2 URL protocol prefix for plaintext http2 over 
>>>the new default port
>>>
>>>This does several things.
>>>
>>>A. It makes plaintext http/2 possible but significantly harder. Some. 
>>>Would argue that makes plaintext http/2 "undeployable"... The same 
>>>people who have argued that have also argued that plaintext http/2 
>>>should not be used at all. Therefore, those people really do not lose 
>>>anything by following this approach.
>>>
>>>B. It makes http/2 over TLS the default for the public internet since 
>>>that's the only option that would be broadly deployable on today's 
>>>infrastructure.
>>>
>>>C. It makes it less likely that we would have to deal with the 
>>>upgrade dance on port 80. Which is a good thing. Http:// URLs would 
>>>always mean http/1.x. Http2://example:80 would mean http/2 over port 
>>>80.
>>>
>>>D. Developers would be forced to make a conscious choice to use 
>>>plaintext http/2 over an established default port. There's zero 
>>>ambiguity.
>>>
>>>The folks who are arguing for TLS only really lose nothing with this 
>>>approach. It still, over course, does nothing about the mitm issues 
>>>on port 443, but its a start.
>>>
>>>- James
>>>
>>>
>