This proposal's purpose is to ... expose all traffic using the http:// scheme to your ISP, exactly as it is today.
Isn't that a semantic requirement of HTTP, though? Half of the "tech" in the HTTP/1.X spec is to allow for caching of resources and responses by proxies, allowing anyone between the client and server (e.g. your ISP) to act as a CDN.
HTTPS/1.X effectively throws that away by doing end-to-end encryption. It's a trade-off: we gain the surety that all the responses are coming directly from the peer, rather than anyone else... but the web becomes 90% less cacheable, because the only places things can end up cached are between the client and the HTTPS pipe (i.e. the browser cache), or between the HTTPS pipe and the server (i.e. "reverse proxies" like Nginx.)
The current workaround for this, when you need caching for your Big Traffic on either ingress or egress, is to do what amounts to purposeful self-MITMing of your HTTPS session: to terminate HTTPS on a caching proxy, that holds the certificate of your client/server, and acts as if it were you, while itself doing another HTTPS session for "the last mile" to connect to you. This is what companies do when they deploy their own CA-cert to their networks, so everyone's access can be proxied through their own system; and this is what services like Cloudflare do when they sit "in front of" your server while not being a part of your company's VPN at all.
Basically, HTTP2 codifies this workaround, and calls it HTTP.
I don't see why you think this is a semantic requirement of HTTP. Perhaps there's some confusion over what HTTP semantics are. Let me refer you to http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2.... It doesn't discuss exposing all HTTP traffic to network intermediaries. Perhaps you're thinking of the HTTP messaging layer http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-2.... Also, I think your statement about allowing an in-path intermediary to act as a CDN is weird, since a CDN is defined as "a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance." [1].
It's true, HTTPS is full of tradeoffs. You've identified some of them.
What do you see in HTTP/2 that "codifies this workaround"? That wasn't immediately obvious to me. Recall that HTTP/2 is basically just multiplexing with prioritized streams. There's no requirement on TLS in the spec, although all current browser deployments (of SPDY) require TLS.
I find it difficult to imagine a world where Applications agnostic caching for encrypted sessions is possible.
I fully expect a world where application developers have services at their disposal for positioning assets closer to the end user with VM instance level isolation and security guarantees.
Transport level security is not likely to be enough for high value/sensitivity data in the long run but adding a bunch of new trusted parties to the system is going to be huge enabler for end user surveillance.
Why application-agnostic? HTTP's own caching isn't application-agnostic; it relies on the server to specify Cache-Control headers.
I would imagine an ideal HTTP2 caching protocol to basically specify that some resources can come from anywhere, as long as the retrieved result conforms to an attached content hash—while also specifying a primary source to get the resource from, if you don't have a DHT handy. (Oddly enough, this is basically a suggestion that web browsers try to resolve magnet: URNs.)
Comments
Isn't that a semantic requirement of HTTP, though? Half of the "tech" in the HTTP/1.X spec is to allow for caching of resources and responses by proxies, allowing anyone between the client and server (e.g. your ISP) to act as a CDN.
HTTPS/1.X effectively throws that away by doing end-to-end encryption. It's a trade-off: we gain the surety that all the responses are coming directly from the peer, rather than anyone else... but the web becomes 90% less cacheable, because the only places things can end up cached are between the client and the HTTPS pipe (i.e. the browser cache), or between the HTTPS pipe and the server (i.e. "reverse proxies" like Nginx.)
The current workaround for this, when you need caching for your Big Traffic on either ingress or egress, is to do what amounts to purposeful self-MITMing of your HTTPS session: to terminate HTTPS on a caching proxy, that holds the certificate of your client/server, and acts as if it were you, while itself doing another HTTPS session for "the last mile" to connect to you. This is what companies do when they deploy their own CA-cert to their networks, so everyone's access can be proxied through their own system; and this is what services like Cloudflare do when they sit "in front of" your server while not being a part of your company's VPN at all.
Basically, HTTP2 codifies this workaround, and calls it HTTP.
I don't see why you think this is a semantic requirement of HTTP. Perhaps there's some confusion over what HTTP semantics are. Let me refer you to http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-2.... It doesn't discuss exposing all HTTP traffic to network intermediaries. Perhaps you're thinking of the HTTP messaging layer http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-2.... Also, I think your statement about allowing an in-path intermediary to act as a CDN is weird, since a CDN is defined as "a large distributed system of servers deployed in multiple data centers across the Internet. The goal of a CDN is to serve content to end-users with high availability and high performance." [1].
It's true, HTTPS is full of tradeoffs. You've identified some of them.
What do you see in HTTP/2 that "codifies this workaround"? That wasn't immediately obvious to me. Recall that HTTP/2 is basically just multiplexing with prioritized streams. There's no requirement on TLS in the spec, although all current browser deployments (of SPDY) require TLS.
[1]: http://en.wikipedia.org/wiki/Content_delivery_network
I find it difficult to imagine a world where Applications agnostic caching for encrypted sessions is possible.
I fully expect a world where application developers have services at their disposal for positioning assets closer to the end user with VM instance level isolation and security guarantees.
Transport level security is not likely to be enough for high value/sensitivity data in the long run but adding a bunch of new trusted parties to the system is going to be huge enabler for end user surveillance.
Why application-agnostic? HTTP's own caching isn't application-agnostic; it relies on the server to specify Cache-Control headers.
I would imagine an ideal HTTP2 caching protocol to basically specify that some resources can come from anywhere, as long as the retrieved result conforms to an attached content hash—while also specifying a primary source to get the resource from, if you don't have a DHT handy. (Oddly enough, this is basically a suggestion that web browsers try to resolve magnet: URNs.)