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

Re: http+aes

From: Ian Hickson <ian@hixie.ch>
Date: Mon, 5 Mar 2012 23:29:16 +0000 (UTC)
To: Willy Tarreau <w@1wt.eu>
cc: URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.1203052326360.6189@ps20323.dreamhostps.com>
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. 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.


> 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.


(We did actually consider something like this.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 5 March 2012 23:29:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT