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 :/

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