Re: HTTP 2.0 mandatory security vs. Amateur Radio

All,

A proposal:

1. Include a discussion of proxy issues inherent in running HTTP/2.0 over plaintext: unreliable, undiscoverable, etc.

2. Include a discussion of common TLS issues - mostly pointers to the appropriate RFCs - that honestly talks about the concerns that have been expressed on this list.

3. Require client and server to support both http:// (with upgrade) and https:// (with ALPN)

4. Place a requirement on public-facing HTTP/2.0 servers: MUST NOT advertise HTTP/2.0 support in response headers, MUST NOT support HTTP/2.0 upgrade. This defines a concrete way to actually “enforce” the use of HTTP/2.0 w/TLS *or* HTTP/1.1 w/o TLS (depending on the client/network capabilities) instead of hand waving and putting the onus on clients to guess whether a connection is local or over the public web.

5. Define/reference a mechanism that allows a HTTP server to advertise that it supports access via https:// - there is at least one draft for this, but this allows a client/user agent to opportunistically use https:// over http://. (For the general case this may not be needed - try connecting on port 443 first, or in parallel with port 80…)


Thoughts?



On Nov 14, 2013, at 3:25 PM, Roberto Peon <grmocg@gmail.com> wrote:

> As I seem to be saying over and over...
> 
> We can wish for plaintext http2 over the internet on port 80 as much as we want, but it won't happen since it is not reliable, and the nature of that unreliability is not predictable.
> 
> Few websites will be willing to turn on http2 if it means losing 10-20% of their user base. And that really is what we are talking about.
> 
> -=R
> 
> On Nov 14, 2013 8:40 AM, "Julian Reschke" <julian.reschke@gmx.de> wrote:
> On 2013-11-14 18:49, Roberto Peon wrote:
> There is a means of opting out, however, which exists and is widely
> deployed: http1
> 
> And the WG has a mandate to develop a replacement for 1.1, called 2.0. If we do not indent to develop that protocol anymore, we should re-charter.
> 
> There was near unanimity at the plenary that we should do something
> about pervasive monitoring, and while I don't believe that there were
> any actuonable , unambiguous dieectuves , the spirit of the room was
> quite clear. The IETF intends to attempt to do something about this.
> 
> Yes. What we disagree on what that means for HTTP: URIs.
> 
> ...
> 
> Best regards, Julian

_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair