Re: Technical Review of EME (DRM in HTML5)

On Mon, Jan 28, 2013 at 6:35 PM, Manu Sporny <msporny@digitalbazaar.com>wrote:

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

To quote from the introduction:

This proposal allows JavaScript to select content protection mechanisms,
control license/key exchange, and implement custom license management
algorithms. It supports a wide range of use cases without requiring
client-side modifications in each user agent for each use case. This also
enables content providers to develop a single application solution for all
devices.


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

It is not the role of this spec to dictate usage policy. It is the
application creator who determines what level of security is desired and
what level of protection to apply. Only the application author understands
what content protection obligations they need to support.


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

You seem to be under the mis-impression that because the ClearKey system
uses keys in the clear that all uses of this spec will be based on ClearKey.


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


And for a very good reason. It is not the goal of this spec to define
specific encryption systems. It is to define an architecture that can
support arbitrary systems. As is made clear in then spec:

All user agents must support the simple decryption capabilities described
in this section regardless of whether they support a more advanced
CDM<https://dvcs.w3.org/hg/html-media/raw-file/tip/encrypted-media/encrypted-media.html#cdm>
. This ensures that there is a common baseline level of protection that is
guaranteed to be supported in all user agents, including those that are
entirely open source. Thus, content providers that need only basic
protection can build simple applications that will work on all platforms
without needing to work with any content protection providers.

As has been pointed out elsewhere in this thread, the inclusion of ClearKey
is more for the purpose of providing a definitive baseline for testing and
content usage scenarios that are satisfied by the simple, low-security
aspects of this method.

Of course, It wouldn't hurt to provide a note to the reader making this a
bit more clear so that readers don't make the wrong assumptions.


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


Not particularly. It is to provide at least a baseline functionality in the
absence of any other supported CDM.


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

A ClearKey CDM system is a trivial implementation exercise. It certainly
does not re-invent TLS nor attempt to do so.


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

Now you have dived into an attempt to define another CDM. It isn't
necessary for EME to define any CDM other than ClearKey. If you wish to
define another CDM in an independent spec, then that would be a separate
activity. You are free to do so.


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

Well, I've said a number of times that you are reading more into this spec
than is there. You seem to want to define specific CDMs with different
characteristics than ClearKey. There's nothing stopping you. But doing so
is not part of the EME spec. Try to think of EME as akin to the
HTMLMediaElement functionality which does not define the use of any
specific codec. It is an architectural feature. I'm sure you understand the
need for reusable abstractions.


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

So? Anyone who would use ClearKey without taking this into account would be
particularly naive. It is not the goal of ClearKey to do more than it does.


>
> and you reply with:
>
> Key protection is out of scope!
>

Correct. It is an aspect of a particular CDM, and different CDMs will
define their own key protection systems. We have no need to do so.


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

No. It is defined to be in the clear. So nothing is broken.


> 2. Take Simple Decryption out of the spec.
>

No. It provides a useful baseline. Application authors will determine which
CDMs they use.


> 3. Don't make Simple Decryption a required feature.
>

No. It provides a useful baseline, is trivial to implement, and plays an
important role in functional and system testing.

So, Manu, I haven't noticed any technical comment from you that is relevant
thus far to EME as defined. Making comments about the limitations of
ClearKey as a CDM system is not particularly useful. Comments that would be
technically useful would be of the form:

   - API X is broken because of ...
   - API X is not feasibly implementable because of ...
   - the EME architecture fails to account for an important use case Y
   because of ...

So far, your comments seem to be of the form:

   - the ClearKey CDM does not provide adequate protection [under some
   assumption of adequacy] ...

This doesn't constitute a technical comment about the EME architecture or
APIs.

Perhaps you can re-review EME with these suggestions in mind. It is certain
that the EME authors and users will listen carefully to any substantive
comments that fall into the first form of comments above. Leave your
comments about specific CDM behavior for follow-on standardization
activities that go the next step of defining new CDMs other than ClearKey.

Regards,
Glenn