Re: A proposal

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