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

Re: http+aes

From: Willy Tarreau <w@1wt.eu>
Date: Mon, 5 Mar 2012 21:08:50 +0100
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: Ian Hickson <ian@hixie.ch>, Yngve Nysaeter Pettersen <yngve@opera.com>, URI <uri@w3.org>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20120305200850.GI30594@1wt.eu>
On Mon, Mar 05, 2012 at 06:09:35PM +0000, Poul-Henning Kamp wrote:
> In message <Pine.LNX.4.64.1203051655450.6189@ps20323.dreamhostps.com>, Ian Hick
> son writes:
> >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.
> I'm sorry, but IMO this is just security-theater, and it represents
> so terrible handling of key-material that it is deeply irresponsible
> to even mention it in a standards document, without a lengthy list
> of caveats and disclaimers.
> Somebody should point Bruce Schneier at this, he needs a good laugh...

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 has the benefit of working out-of-the-box without affecting existing
intermediary components.

Received on Monday, 5 March 2012 20:10:33 UTC

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