HTTP2 [pdf]
daniel.haxx.se
daniel.haxx.se
This may be a big issue, and may impact net neutrality. You get better performance if your stuff is inside a pipe from a Big Service. This makes Google look good. It also increases the relative benefit of running everything through a content delivery service.
This, in turn, creates a use case for CDNs which suck up all the components needed to display a page by whatever means necessary and deliver them to the end user over one HTTP2 connection. It then makes sense for the CDN, not the end user page, to be the advertising insertion point. If ads are loaded from a third-party ad server, they might not show up before the user is done viewing the page. This sometimes happens now. With server-side control of ordering within a single HTTP2 pipe, advertisers tied in with the CDN can be sure that ads will appear when the advertiser wants them to appear.
So there's a net neutrality issue. When multiple streams are multiplexed over a single pipe, the server gets to determine who goes first. Control over that order is valuable. That control may end up in the hands of the CDN, not the site operator.
I see how this could potentially shift the ad-bearing responsibility to CDNs, but I'm not seeing how it's any more of a net neutrality issue than what we've got now. Could you propose a hypothetical scenario?
There's also an encryption issue. The big pipe is one SSL/TLS session under a single key. Whoever owns the big pipe gets to see everything. Things like embedded Facebook content, normally encrypted with Facebook's keys, can't go through the big pipe unless they accept the CDN looking at their traffic.
It's not clear how all this plays out, but it definitely implies more centralization.
It's currently implemented as a layer over UDP: http://en.wikipedia.org/wiki/QUIC
There'll definitely be some Googlers paying attention to the WG to ensure that the two protocols play well together.
I think in the future all protocol diagrams should use colored lego blocks. That was fantastic.
I think this whole CA system is needlessly complex. Your registrar should be providing you with a free certificate for your domain and that should be the end of the hassle.
You can publish and sign your TLSA records today, without interfering with your current CA signed certificates.
https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na...
Every CA that issues DV certs for public DNS names takes registrars' databases as the ultimate ground truth about domain ownership -- at least for the domains that the CA is willing to issue for -- so the DV-cert-issuing world is reliant on them to be correct, secure, up-to-date, and so on. That's true whether the CA is using whois data plus DNS data, or just DNS data, to verify domain control.
(In saying that, I thought about the idea that Let's Encrypt may use safeguards to limit issuance based on historical observations of domain control and prior issuance history by other CAs. For example, our draft ACME spec has a mechanism where we could ask a requestor to prove control of an existing subject key from a cert that we know was issued for the same subject domain by another CA. So if we've already seen a valid cert in the wild, or in Certificate Transparency, for example.com, we could say that you have to show that you have control of the key in that cert before you can get a new cert from Let's Encrypt for example.com. But all of those things ultimately go back to what registrars said in the past, even if some of them are independent of what registrars say today.)