Re: http+aes

On Mar 6, 2012, at 11:57, Willy Tarreau wrote:

> Maybe there is something that I did not
> understand then.

Maybe I'm beating a dead horse, but the use case is pretty obvious.

A is a user with their browser.
C is a "content" "owner".
B is a CDN.

A has C's website open and wants to view a movie.
C wants you use B for the delivery of that movie, but doesn't trust B very much.
C does trust A a lot, though (I don't know why, but see below).
So C gives A a reference to content in B that only A will know how to decrypt.
For implementation convenience, we encode both the reference and the keying material in one thing, a URI.
(See my previous message on how to do this in a cleaner way.)

Why does this make any sense whatsoever?
You have to make a quantitative argument; on the qualitative level it doesn't.
The reason is that a CDN that has a copy of all of C's movies is a big treasure chest, and "C trusts B" in reality means "B is prepared to incur a lot of liability towards C if things go wrong".
C may not trust A that much either, but at least A only gets one movie and not the whole treasure chest.

This is not a very bright security scheme (A can hand out the URI+key to all their friends and megaupload as well).  But maybe it is good enough for "DRM".  It's certainly better than leaving the treasure chest on B, if C wants to encourage competition between Bs and lower their price for engaging Bs.  (C can limit the damage by rotating the copies on all of its Bs relatively quickly, which may still be less bandwidth than from A to all Cs.  There are some pretty obvious ways to do fingerprinting here, as well.  And then there is DECADE...)

The specification for this would have to make clear the limited applicability of this scheme.  This may be one reason not to have it in the HTML spec, because that is very big already and is not a good place for rationale, applicability etc.  Whether saying "this is not a new solution to the HTTPS problem" is going to help at all -- we can argue that a long time.

Grüße, Carsten

Received on Wednesday, 7 March 2012 14:22:32 UTC