RE: http+aes

Ian,

>> 1. Encryption without integrity (as http+aes delivers) is almost 
>> worthless. It rarely delivers the security that you expect.

> The security that we expect here is exclusively that an untrusted CDN 
> can't copy the data. As far as I can tell, this is indeed the security 
> provided by this proposal.

This is not the security you get. It does make it more awkward for a rogue CDN employee to get the content of, say, a movie. He cannot just copy the file from a disk in the CDN. But the rogue CDN employee can still copy the movie by tinkering with one response to one user. [For instance, replace a known part of the movie (eg common header) with malware that returns the key (XOR the ciphertext with the known-part (exposing that part of the keystream) then XOR with the malware).]


> The use case is specifically one that assumes that the attacker, in this 
> case the untrusted CDN, is not in a position to damage the content.
>
> This seems like a very reasonable assumption.

I totally disagree. If the rogue employee damages all the content (so it no longer works) to all users all the time then the CDN will lose its business pretty quickly. However, the attack can be against individual users and it doesn't even need to disrupt the movie (the inserted malware can expose the key and continue playing the movie).



A URL hack (eg key material in the userinfo field); http hacks (body no longer matches content-type header; errors screwed up; redirects break); a crypto hack (encryption without integrity)... to tackle one way to violate privacy while other (somewhat more complex) ways remains for the same attacker. This is not a good candidate for a standard, certainly not for HTML5.



>> Is the content after following the redirect supposed to be encrypted or 
>> not?

> It is not, just like if an HTTP site redirects to an FTP URL, you don't 
> use the HTTP protocol with the FTP site.

Ugh? So if the CDN web site introduces a redirect before returning the encrypted content it will break (the user-agent now expects plaintext)!


>> HTTP errors (with a response body) will, presumably, not be encrypted.

> As specced, they would be decrypted (into garbage).

Argh. Gratuitously breaking HTTP.


> There is no way to determine if the body is cleartext or not. By 
> definition, it is encrypted.

Not setting a content-type (or content-encoding) to indicate the encryption is more gratuitous breaking of HTTP (for no reason - presumably CDNs can be configured with content-type header values).


--
James Manger

Received on Wednesday, 7 March 2012 01:49:19 UTC