On Fri, Nov 15, 2013 at 8:54 AM, Yaakov Stein <yaakov_s@xxxxxxx> wrote:
> That aside, just saying "you MUST do TLS with HTTP/2.0" doesn't buy much security in a worldI believe that this proposal was in line with Bruce Schneier's suggestion at the plenary.
> 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.
Do anything to make more work for people trying to listen in to everything on the Internet.
For example, put a key at the top of the content and then encrypt using this key.
This is meaningless from the confidentiality point of view,
but eats up computational resources and energy for someone trying to vacuum up everything.
Even better - when you don't have anything to transmit, send meaningless supposed encrypted packets.
If everyone did this their storage costs would skyrocket.
Even better, send packets with easily broken encryption containing keywords of interest.
I made a similar proposal at the link layer, which I think is where things like flood fill really belong.
At the HTTP layer, there is no point in passing raw keys in band. At least do a DH exchange.
The problem I have with TLS everywhere is that TLS is a pretty heavy protocol stack with a huge amount of complexity and HTTP/2.0 is meant to be reducing complexity. I think what the people are really trying to do is to optimize HTTP for the narrow use case they are familiar with. Which is not what I want which is to reduce the complexity.
I recently proposed a fix for HTTP authentication cookies that exchanges a key in-band:
Now that scheme could be easily modified to add in a D-H exchange so as to provide ephemeral keying and defend against pervasive attack. And it would be very easy to add in encryption of the message content. In fact the original prototype actually did just that. It is even possible to specify a new key with the content which allows cached content to be encrypted.
This approach gives all the security advantages of weak-SSL-everywhere without the cost of kicking the proxies in the head and disrupting caching and all the other problems that the proposaed change in the security model will cause.
Website: http://hallambaker.com/