W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: http+aes

From: Willy Tarreau <w@1wt.eu>
Date: Tue, 6 Mar 2012 07:55:07 +0100
To: Ian Hickson <ian@hixie.ch>
Cc: URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20120306065507.GF2930@1wt.eu>
On Mon, Mar 05, 2012 at 11:29:16PM +0000, Ian Hickson wrote:
> On Mon, 5 Mar 2012, Willy Tarreau wrote:
> > 
> > I wouldn't go to such extremities, but at least I think that we're just 
> > facing a layering violation. Only the contents have to be encrypted so 
> > that the caches cannot use them, while the transport remains unchanged. 
> > So a new scheme is not appropriate for this, a Content-Encoding would be 
> > much better. User agents would be configured to know that content- 
> > encoding XYZ requires a deciphering key whose ID is presented in the 
> > header itself and should have been retrieved via another channel.
> > 
> > Example :
> >     Content-Encoding: aes-ctr-128; keyid=0x34751806
> >     Cache-control: no-transform
> This would require changes at the intermediaries.

If your goal is that intermediaries don't know the contents then no,
doing this is enough for existing intermediaries to cache the contents
without touching it and without understanding it.

> It would also require a 
> mechanism to link keys to IDs, which is non-trivial given the same-origin 
> policy, multiple browsing contexts, subresources, etc.

So you mean that it's the *real* decryption key which is passed in userinfo ?
It appeared obvious to me that it was just an identifier for a key that the
client had fetched somewhere else (eg: on the same site via https or at least
without passing via the CDN). If the real key is passed in the response, then
I fail to get the use case since your CDN gets the key as well :-/

> > This has the benefit of working out-of-the-box without affecting 
> > existing intermediary components.
> It would seem to me to require slightly more effort than the scheme 
> approach on this front.

It depends on how far the http+aes scheme is visible. Will a browser send
"GET http+aes://xxxxx HTTP/1.1" to a browser or will it know that it must
use the "http" scheme when asked for "http+aes" ?  And what scheme will be
used for redirects ? Will cookies be passed to http+aes requests ? Will
javascript be able to perform http+aes requests, and if so, what are the
security implications (eg: will it make it possible for malware to build
huge collections of deciphering keys and make them public).

It doesn't look like it's that much obvious to me.

Received on Tuesday, 6 March 2012 06:55:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC