Re: [IAB] Mandatory encryption as part of HTTP2

[Phillip Hallam-Baker <[e-mail]>]

On Fri, Nov 15, 2013 at 8:54 AM, Yaakov Stein <[e-mail]> wrote:

> > 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.
>
> I believe that this proposal was in line with Bruce Schneier's suggestion
> at the plenary.
> 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:

https://datatracker.ietf.org/doc/draft-hallambaker-httpsession/


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/