Re: http+aes

On Mon, 5 Mar 2012, Yngve Nysaeter Pettersen wrote:
> > 
> > http://whatwg.org/html#http-aes-scheme
> 
> This definition (and the HTTPS+AES one) leaves a lot to be desired, IMO
> 
> * What are the use cases?

The use case is being able to get private data from a provider A to a 
client C via an untrusted intermediary B, where the lack of trust is 
specifically over whether or not the intermediary will look at the data 
(as opposed to whether they will attempt to manipulate the data, which 
would be readily detectable and thus put an end to the A-B relationship 
typically via a lawsuit). The use case is addressed by encrypting the 
content before sending it to B (typically a CDN) and delivering the key 
with any URL referring to that content directly from A to C.

For example, the content could be a movie. "A" would be a movie 
distributor, "C" would be a consumer, and "B" would be a CDN. B is paid by 
A to host the content, but B might have rogue elements who would take all 
of the movie content and upload it to a copyright-violating community.

Another example would be YouTube with private videos. YouTube would like 
to cache private videos at the edge of the network on CDNs, but might want 
to use CDNs whose integrity is not entirely trusted.

Similar situations exist with other content types.

In both cases, this solution addresses the problem by encrypting the 
content at B (the CDN) such that the CDN cannot make use of the files, and 
serves the key directly from A's servers.

(We don't generally include rationale in the HTML spec, for practical 
reasons, though if anyone is interested in working with us to document 
them I'd be happy for the help; contact me off-list.)


> * Why is it better than using HTTPS?

The attack scenario is that the CDN itself isn't trusted not to look at 
the data. HTTPS only helps with on-the-wire attack scenarios.


> If the URL is sent over HTTPS you will very likely already have at least 
> one persistent HTTP connection open to the server (assuming it is the 
> same server) so establishing a new connection (same or different server) 
> for this request is not going to increase performance.

Relative to the current setup, there are no additional connections; the 
only difference is that the content at B (the CDN) is encrypted.


> * What is the keymaterial? If the userinfo is the key, how is it 
> encoded? Base64, hex, calculated (how?), or other format

The key is the userinfo value. (It's escaped in the URL, using the normal 
URL escaping rules.) I believe this is clear in the spec; let me know if 
the current text is ambiguous on this.


> where is the CTR nonce encoded?

The key is fresh per resource, so there's no need for a nonce, so it's 
zero. I've clarified this in the spec.


> * If the keymaterial is intended for long-term usage by a single user, 
> depending on storage methods, how is the keymaterial info migrated 
> securely to a new client, either for parallel use in multiple clients, 
> or system recovery?

There is typically going to be one key per encrypted resource. It is 
transmitted to the client with the URL; in normal operation, this would be 
done over HTTPS, from A to C directly. I'm not aware of a use case where 
it would need to be stored for long-term usage.


> * Given that this is probably going to be MITM vulnerable when used over 
> plain HTTP, what should the client do if the URL is provided over HTTP 
> (or included by reference in a document loaded over HTTP)? Refuse to 
> perform the request, or go ahead anyway?

Anything transmitted over HTTP over an untrusted network is unsafe. 
There's not really anything more serious here than generally. It would be 
impossible to generically determine if the URL was obtained over encrypted 
channels or not (e.g. consider a URL constructed from parts obtained 
using XMLHttpRequest over both encrypted and unencrypted channels), so I 
don't think there's much point trying to block this.


> * How does this interact with other ongoing specification work, such as 
> the Javascript Crypto APIs?

It does not, as far as I can tell. I'd be happy for this feature to be 
moved to a more appropriate spec if there is one, though.


> * How will this interact with clients that does not understand the URL 
> scheme?

They won't be able to access the content.


> It is quite possible that they will display the userinfo in the 
> addressbar or the resulting error messages.

Displaying the userinfo to the user isn't particularly bad (it's random 
data, and the user is implicitly trusted with it anyway). Other attack 
scenarios in this situation seem like they'd apply to any bogus URL, and 
would need addressing independent of this scheme.


I believe this answers all the technical questions on this thread so far, 
let me know if I missed any.

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 5 March 2012 17:55:32 UTC