Re: How HTTP 2.0 mandatory security will actually reduce my personal security

I find myself emphatically agreeing with pretty much everything Michael
says in this thread.
On Nov 15, 2013 7:50 AM, "Michael Sweet" <msweet@apple.com> wrote:

> Roberto,
>
> On Nov 15, 2013, at 3:00 AM, Roberto Peon <grmocg@gmail.com> wrote:
>
> There is explicitly an option for unencrypted HTTP/2, but not over the
> "open" internet, since that is known/provent to be unreliable.
>
>
> I have a real problem with trying to spec “don’t do this over the open
> Internet”.
>
> And IIRC the IETF frowns on protocols that special-case local usage - the
> assumption that Internet access to http:// URIs usually occurs through
> proxies while https:// URIs are “safe” has already been shown to be
> invalid, and I suspect that organizations that deploy proxies may not limit
> their use to “outside” traffic, so local access may indeed have the same
> issues as remote, for both http:// and https:// URIs.
>
> The challenge, then, is how we can work with the HTTP/1.1 rules for
> proxies instead of trying to work around them.  Otherwise we really do have
> a completely new protocol and need to treat it as such (new port number,
> http2:// URIs, etc.)
>
>
> And in my personal opinion, HTTP is a poor mechanism for cached content:
> it allows for a very limited distribution model and (amongst other things)
> doesn't adequately differentiate between resources that should be public,
> but verifiably unmodified, and private resources.
> I wish that we had a different protocol (and I've been talking about this
> for a while actually) for public, cacheable content. I've proposed such in
> the past, but don't have the bandwidth to work on it until HTTP/2 is done.
> The basics of the (now old, but still unimplemented) idea there are,
> however, that everything is a subset of peer-to-peer, and thus the large
> part of the innovation that should be done is in the policy about how the
> data is to be distributed in a potentially peer-to-peer network
> As an example, imagine a policy which could indicate that, for any
> arbitrary byterange of a resource first try from the origin, then the local
> ISP supernode, and if those fail, try from peers.
> In this imagined world/protocol, the SlashDot effect would be a thing of
> the past, even for those sites not using a CDN, since the more users there
> were of a site, the more peers there would be for the content.
> ... but this is waaaaay off topic now.
>
> -=R
>
>
> On Thu, Nov 14, 2013 at 11:48 PM, Bruce Perens <bruce@perens.com> wrote:
>
>>  On 11/14/2013 11:32 PM, Roberto Peon wrote:
>>
>> For 1,2: How is this not orthogonal to the rest of the discussion?
>> For 3: I'm assuming you mean because the data is encrypted. You can MITM
>> this.
>>
>>  Just to be sure we're all on the same page here (because it seems that
>> we're not):.
>>   As I understand it, the proposal is:
>>     For web activity on the "open internet", if the scheme is https,
>> attempt to use http/2 over an encrypted, authenticated channel.
>>      For web activity on the "open internet", if the scheme is http, use
>> http/1 over an unencrypted, plaintext channel.
>>     For activity on a private network: use any combination of
>> {authenticated, unauthenticated}{encrypted, unencrypted}{http2,http1} you
>> desire.
>>
>>  Is there an objection to this?
>>
>>  Yes. It's stating that the only possible use of unencrypted http must
>> be via http/1.1 . It's either assuming that we must support http/1.1
>> forever, in which case that perpetual support should be part of the http 2
>> specification; or it's assuming that http/1.1 will wither and that this
>> will eventually force everyone to use encrypted traffic always.
>>
>> Neither of these seem optimal. The proposal ignores the fact that the
>> vast majority of web traffic is immutable public content for which
>> encryption serves no real purpose, and that the transmission of this
>> content may benefit from innovations in http/2 other than encryption.
>>
>> By the way, when I really feel the need to encrypt something, I use the
>> one-time pad. Depending on anything else is optimistic.
>>
>
>
> _______________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>