Re: Technical Review of EME (DRM in HTML5)

On 01/26/2013 11:12 PM, Glenn Adams wrote:
> 
> On Sat, Jan 26, 2013 at 5:41 PM, Manu Sporny
> <msporny@digitalbazaar.com <mailto:msporny@digitalbazaar.com>>
> wrote:
> 
> Let me be crystal clear. I would be delighted if this specification 
> figured out how to create an open and inter-operable DRM ecosystem
> that was simple to implement, that was fair to content creators and
> viewers alike, and that would work across all browsers on all
> platforms. Really, I would.
> 
> You appear to misunderstand the scope/goals of the EME spec.
> Defining "an open and inter-operable DRM ecosystem" is not in scope.
> The EME abstract [1] makes this clear, so it is clear that you start
> your comments based on a false assumption.

I was trying to be clear about what I would like to see, not the problem
that the specification is attempting to solve, which continues to be
stated in vague terms. That statement above wasn't the basis for my
technical analysis, I state the basis in the blog post.

What problem is the specification attempting to solve? I'm not being
facetious, I am trying to understand.

> The issue of content key protection is also clearly marked out of
> scope [2], so your comments on protection of key secrets are
> similarly based on a false assumption.

I didn't assume content key protection was in scope. I know what the
spec text says. I'm asserting that the spec should say /something
substantial/ about content key protection. At least let folks know that
transmitting keys in the clear is a horrible security practice and that
they should never use Simple Decryption.

The spec marks content key protection out-of-scope and then it goes on
to transmit decryption keys in the clear. That seems incredibly backwards.

The only protection mechanism that is actually spec'd is this:

https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#simple-decryption

The key isn't protected at all, it's transmitted in the clear. My
assumption is that this is done to get around the "multiple
inter-operable implementations" requirement at W3C. However, the
"protection" mechanism provided in that section basically reinvents TLS
(but in a way that is not secure at all) and it is REQUIRED to be
implemented by browser manufacturers.

Alternative: Have the browser generate a random token that could be
tracked by the license server to ensure that a single clear-key can't be
reused by another User Agent. This solution has it's own problems, but
it isn't that much more complicated than what's already in the spec and
it would at least provide some level of "protection" against decryption
key copying. It wouldn't be that difficult to implement this and it
would provide more security than the no-op that is "Simple Decryption".

> I'd suggest you carefully reread the abstract and other statements
> in EME that clearly delineate the scope of this spec, and reformulate
> your comments accordingly.

I did read the abstract, multiple times. I also read the specification
multiple times. You have not presented any information in this e-mail
that I didn't know when I wrote the blog post. The blog post remains
unchanged.

I'm trying to understand why the technical points I raised in the blog
post are wrong. When I say something like:

Not having a key protection mechanism for the Simple Decryption feature
makes the system open to attack.

and you reply with:

Key protection is out of scope!

That doesn't address the point I am making. To address the point I'm
making, you'd have to do at least one of the following:

1. Fix key protection in the Simple Decryption mechanism.
2. Take Simple Decryption out of the spec.
3. Don't make Simple Decryption a required feature.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Aaron Swartz, PaySwarm, and Academic Journals
http://manu.sporny.org/2013/payswarm-journals/

Received on Tuesday, 29 January 2013 01:36:11 UTC