- 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>
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.
Regards,
Willy
Received on Monday, 5 March 2012 20:10:33 UTC