The fact that you are ignoring the deployment reasons for using encryption,
which are orthogonal to any security reasons is part of the reason why it
is frustrating for me to not have you participate or at least read the
discussions going on within the httpbis list.
-=R
On Nov 15, 2013 4:55 AM, "Iljitsch van Beijnum" <iljitsch(_at_)muada(_dot_)com>
wrote:
On 15 nov 2013, at 12:14, Hannes Tschofenig
<hannes(_dot_)tschofenig(_at_)gmx(_dot_)net>
wrote:
We mandate other things in protocol specification as well (that aim to
take performance, for example, to a specific level) then why not also
certain security features.
I'm all for mandating certain security features. A big part of that is not
having insecure stuff in version 1 of protocols, because once the can is
open, the worms never (completely) crawl back in. However, mandates in the
form "if you do X you may only do it in manner Y" don't mean much, because
the IETF has no real-world power beyond the text of its specifications.
That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy much
security in a world where CAs are not trustworthy, people still use
RC4/MD5, use woefully short keys for otherwise strong algorithms, browsers
have effectively trained people to always click "visit anyway" and so on.
Also, there are cases where encryption isn't needed, and cases where it's
not desired. An example close to home: a while back, some IETF meeting
related page, the agenda perhaps, would only be available over HTTPS. And
it was extremely slow. Not sure if this was because the server was
overloaded, session keys were negotiated every time (which shouldn't be
necessary) or the page wouldn't be cached (which should be possible), but
the end result was that a static file that is available to everyone without
credentials was much harder to access for no benefit. Unless you pad all
your pages as well as their URLs to the same length, it's trivial for
snoops to see who got which page simply by observing the length of the
exchange.
With security, the perfect tends to be the enemy of the good. Let's focus
our efforts on getting everything encrypted that needs to be encrypted, and
do so according to the state of the art rather than sloppily as often
happens today, rather than fight over whether people get to serve
unencrypted stuff over HTTP/1.1 or HTTP/2.0. "Encrypt everything" makes for
a good soundbite, but it's a terrible policy.