Re: A proposal

For those for whom plain text http/2 is important,  it will be
implemented.  For those who don't care,  they won't bother.  If it becomes
important enough,  the tooling will emerge.
On Nov 17, 2013 1:01 PM, "Roberto Peon" <grmocg@gmail.com> wrote:

> 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 :/
>
> Happy eyeballs-like strategies either introduce latency or introduce
> complexity, and sometimes both. For fun: which connection do you send any
> particular request down?
>
> 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.
>
> -=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
>>
>>
>