Re: A proposal

as a web site operator and web user, I don't want to be pushed towards 
https and have life made more difficult to remain plaintext.  That 
overall will just make my life more difficult.

I want to be able to leave it as is.  It would be nice to know if my 
https is being intercepted, but if I'm worried, I can check the cert.  
Something more deterministic would be better so I didn't have to look, 
since it's a pain to drill into the cert.

There's another aspect we haven't discussed either.

Client side caches don't just free up client side resources - they also 
save server resources.  A client that doesn't have to make another 
request, saves the server from dealing with it.

So, compulsory (or heavily skewed towards) crypto by introducing pain 
into the plaintext option will increase server requirements for more 
reasons than just the crypto CPU burden which we already have a problem 
with.  There will also be an increase in requests due to reduced 
cachability (e.g. in intermediary caches).

Adrien


------ Original Message ------
From: "James M Snell" <jasnell@gmail.com>
To: "Zhong Yu" <zhong.j.yu@gmail.com>
Cc: "Tim Bray" <tbray@textuality.com>; "ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>; "Poul-Henning Kamp" <phk@phk.freebsd.dk>; "Mike 
Belshe" <mike@belshe.com>
Sent: 18/11/2013 10:44:19 a.m.
Subject: Re: A proposal
>It intentionally pushes people towards https in the default most common 
>cases while making it still possible to do plaintext...
>
>On Nov 17, 2013 1:27 PM, "Zhong Yu" <zhong.j.yu@gmail.com> wrote:
>>The current spec already allows plain http2. What does your proposal
>>try to achieve? My impression was that you want to make it more
>>reliable on open web. But later you sounded like you want to make it
>>less reliable. (In no way I'm trying to question your intention; this
>>thing is too complicated and we are all lost in words)
>>
>>
>>
>>On Sun, Nov 17, 2013 at 3:19 PM, James M Snell <jasnell@gmail.com> 
>>wrote:
>> > The proposal is to make it possible but with additional steps.  As 
>>opposed
>> > to the other proposal that says no plaintext http/2 at all.
>> >
>> > On Nov 17, 2013 1:17 PM, "Zhong Yu" <zhong.j.yu@gmail.com> wrote:
>> >>
>> >> On Sun, Nov 17, 2013 at 2:57 PM, James M Snell <jasnell@gmail.com> 
>>wrote:
>> >> > This proposal doesn't change that assumption.  It just says that 
>>if you
>> >> > see
>> >> > http:// that means http/1.x. If you see https, that means TLS 
>>with
>> >> > either
>> >> > http/1.x or 2.0. You only get plain text http/2 if you use the 
>>new
>> >> > scheme.
>> >> > That ought to sufficiently make plain text http/2 largely 
>>undependable
>> >> > on
>> >> > the broader Web,  while still allowing those who really want it a 
>>means
>> >> > of
>> >> > doing so.
>> >>
>> >> I'm confused - is it your objective to make plain http2 more
>> >> undependable on the broader web? Since your wording sounds like 
>>that.
>> >>
>> >> >
>> >> > If someone wants to use a response header or DNS or whatever to
>> >> > advertise
>> >> > that they support plaintext http/2, then they may do so.  But 
>>that's an
>> >> > orthogonal issue.
>> >> >
>> >> > On Nov 17, 2013 12:45 PM, "Tim Bray" <tbray@textuality.com> 
>>wrote:
>> >> >>
>> >> >> Yeah, Mike’s right; the proposal is architecturally cool, I like 
>>it;
>> >> >> but
>> >> >> the universe of Web content is completely permeated with 
>>hardcoded
>> >> >> “http://”
>> >> >> and “https://” (static files, code, and templates) and I think 
>>we have
>> >> >> to
>> >> >> live with that :(
>> >> >>
>> >> >>
>> >> >> On Sun, Nov 17, 2013 at 12:32 PM, Mike Belshe <mike@belshe.com> 
>>wrote:
>> >> >>>
>> >> >>> I think I replied earlier, but I am strongly against any 
>>proposal
>> >> >>> which
>> >> >>> introduces new URL scheme for HTTP.
>> >> >>>
>> >> >>> This is changing the UI of the web, which most users don't 
>>understand
>> >> >>> (and shouldn't need to).  Right now, users don't have to know 
>>about
>> >> >>> HTTP2 vs
>> >> >>> HTTP1.1 vs HTTP1.  If we make them have to differentiate, we've 
>>really
>> >> >>> screwed up badly.
>> >> >>>
>> >> >>> This would also open a new set of security risks, as you'd now 
>>have to
>> >> >>> deal with sites that include resources from http: and http2:, 
>>and is
>> >> >>> that a
>> >> >>> mixed-content warning?  I think it would have to be.
>> >> >>>
>> >> >>> Finally, this would make server side deployment very hard - 
>>there are
>> >> >>> a
>> >> >>> tremendous number of applications (php, java, etc) with 
>>'http://' hard
>> >> >>> coded, and all of those would have to change.
>> >> >>>
>> >> >>> Mike
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> On Sun, Nov 17, 2013 at 12:15 PM, Zhong Yu 
>><zhong.j.yu@gmail.com>
>> >> >>> wrote:
>> >> >>>>
>> >> >>>> If a URL is http://something, it better means that the 
>>document can
>> >> >>>> be
>> >> >>>> retrieved by HTTP/1 on clear TCP. If that assumption is 
>>broken, a lot
>> >> >>>> of software will be broken.
>> >> >>>>
>> >> >>>> On Sun, Nov 17, 2013 at 1:58 PM, Poul-Henning Kamp
>> >> >>>> <phk@phk.freebsd.dk>
>> >> >>>> wrote:
>> >> >>>> > In message
>> >> >>>> >
>> >> >>>> > 
>><mailto:CACuKZqE4DDsZif_WA%2BfguDFXEJwHbVUKt6FdC-2CMqR5dWgiHA@mail.gmail.com>
>> >> >>>> > , Zhong Yu writes:
>> >> >>>> >
>> >> >>>> >>As a web page author, how do I choose which scheme, http:// 
>>or
>> >> >>>> >>http2://, to use for a link? Do I need to detect the browser
>> >> >>>> >> version
>> >> >>>> >>the page is rendered on?
>> >> >>>> >
>> >> >>>> > Right now we have two schemes in common use:  "http" and 
>>"https"
>> >> >>>> > and people in both ends of the HTTP connection interpret 
>>that
>> >> >>>> > (more or less) as "without privacy" and "with privacy"
>> >> >>>> > respectively.
>> >> >>>> >
>> >> >>>> > This is counter to the IETFs ratified semantics of the 
>>scheme as
>> >> >>>> > protocol selector for these two values, but I think we will 
>>shoot
>> >> >>>> > ourselves big holes in the feet, if we try to press the IETF
>> >> >>>> > view down over everybodys head, as a preconditition for 
>>using
>> >> >>>> > HTTP2.
>> >> >>>> >
>> >> >>>> > The choice of HTTP/1 vs. HTTP/2 should be decoupled from the 
>>HTML
>> >> >>>> > and from the browsers URL field, and therefore I cannot 
>>support
>> >> >>>> > James proposal.
>> >> >>>> >
>> >> >>>> > My counter proposal:
>> >> >>>> >
>> >> >>>> > 1. HTTP/2 on port 100 is always plaintext, which makes life 
>>easy
>> >> >>>> >    for network people and is conceptually simple for 
>>everybody
>> >> >>>> >    to understand.  It also does not need any RTT before 
>>HTTP/2
>> >> >>>> >    performance benefits kick in.
>> >> >>>> >
>> >> >>>> > 2. Encrypted HTTP/2 will go over 443 (if SSL/TLS is used, 
>>otherwise
>> >> >>>> >    I suspect that will need a new port too ?)  This makes 
>>life
>> >> >>>> >    easy and is conceptually easy to understand too.
>> >> >>>> >
>> >> >>>> > 3. Servers or intermediaries which can do HTTP/2 (port 100 
>>and/or
>> >> >>>> >    443) can indicate this two ways:
>> >> >>>> >
>> >> >>>> >    a) By sending a header in only the *first* HTTP/1 
>>response on
>> >> >>>> >       any connection.
>> >> >>>> >
>> >> >>>> >       This new header must be listed in "Connection:" since
>> >> >>>> > protocols
>> >> >>>> >       supported is by nature a hop-by-hop property.
>> >> >>>> >
>> >> >>>> >       (For further study:  Make this a general purpose 
>>header which
>> >> >>>> >       can also indicate HTTPS, SCTP or other protols 
>>supported ?)
>> >> >>>> >
>> >> >>>> >    b) In DNS records. (For futher study:  How ?)
>> >> >>>> >
>> >> >>>> >    Servers should do both. Intermediaries can only do a).
>> >> >>>> >
>> >> >>>> > 4. URIs in HTML documents do not change.
>> >> >>>> >
>> >> >>>> >         "http:" means "no privacy needed"
>> >> >>>> >         "https:" means "privacy required"
>> >> >>>> >
>> >> >>>> >    The user-agent gets to resolve that into HTTP/1 and 
>>HTTP/2 (or
>> >> >>>> >    any other protocols), according to policy, preference and
>> >> >>>> > custom,
>> >> >>>> >    based on server provided information, possibly cached.
>> >> >>>> >
>> >> >>>> > 5. Upgrading a HTTP/1 connection on port 80 to HTTP/2 will 
>>not
>> >> >>>> >    be supported, the risk of reducing web relibility is too 
>>high
>> >> >>>> > and
>> >> >>>> >    it would add RTT costs before HTTP/2 performance benefits 
>>kick
>> >> >>>> > in.
>> >> >>>> >
>> >> >>>> > 6. Upgrading a HTTP/1 connection on port 443 to HTTP/2 is 
>>desired
>> >> >>>> >    only if HTTP/2 cannot be a negotiated option during the 
>>TLS -
>> >> >>>> >    handshake.  I don't know the answer to this one, it may 
>>for
>> >> >>>> >    further study ?
>> >> >>>> >
>> >> >>>> > --
>> >> >>>> > Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
>> >> >>>> > phk@FreeBSD.ORG         | TCP/IP since RFC 956
>> >> >>>> > FreeBSD committer       | BSD since 4.3-tahoe
>> >> >>>> > Never attribute to malice what can adequately be explained 
>>by
>> >> >>>> > incompetence.
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >