On 2014-09-11, at 22:55, Henri Sivonen <hsivo...@hsivonen.fi> wrote: > Moreover, https://tools.ietf.org/html/draft-ietf-httpbis-http2-encryption-00 > has the performance overhead of TLS, so it doesn't really address the > "TLS takes too much compute power" objection to https, which is the > usual objection from big sites that might particularly care about the > performance carrot of HTTP/2. It only addresses the objection to https > that obtaining, provisioning and replacing certificates is too > expensive. (And that's getting less expensive with HTTP/2, since > HTTP/2 clients support SNI and SNI makes the practice of having to get > host names from seemingly unrelated domains certified together > obsolete.) > > It seems to me that this undermines the performance carrot of HTTP/2 > as a vehicle of moving the Web to https pretty seriously. It allows > people to get the performance characteristics of HTTP/2 while still > falling short of the last step of to make the TLS connection properly > authenticated.
The view that encryption is expensive is a prevailing meme, and it’s certainly true that some sites have reasons not to want the cost of TLS, but the costs are tiny, and getting smaller (https://www.imperialviolet.org/2011/02/06/stillinexpensive.html). I will concede that certain outliers will exist where this marginal cost remains significant (Netflix, for example), but I don’t think that’s generally applicable. As the above post shows, it’s not that costly (even less on modern hardware). And HTTP/2 and TLS 1.3 will remove a lot of the performance concerns. I’ve seen it suggested a couple of times (largely by Google employees) that an opportunistic security option undermines HTTPS adoption. That’s hardly a testable assertion, and I think that Adam (Roach) explained the current preponderance of opinion there. The current consensus view in the IETF (at least) is that all or nothing approach has not done enough to materially improve security. One reason that you missed for the -encryption draft is the problem with content migration. A great many sites have a lot of content with http:// origins that can’t easily be rewritten. And the restrictions on the Referer header field also mean that some resources can’t be served over HTTPS (their URL shortener is apparently the last hold-out for http:// at Twitter). There are options in -encryption for authentication that can be resistant to some active attacks. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
