Re: Request to add parameters to createSession (bug 17660)

On Oct 19, 2012, at 4:08 PM, Joe Steele wrote:

Replies inline --

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Oct 19, 2012, at 12:45 PM, Mark Watson wrote:

Hi Joe,

I tend to agree with Steven, though I also completely agree with what you say below about TLS.

One of the objectives of the EME was to enable client scripts to be largely or entirely keysystem-agnostic (except in the actual selection of a preferred keysystem, when there is a choice). As things stand the procedure is always the same: take the initData from the needkey event, pass it back to create a MediaKeySession and then ferry messages to and fro between the CDM and the application server.

Adding a space for appData creates scope for keysystems to place keysystem-specific requirements on what that contains, requiring keysystem-specific procedures on the client side.

If, however, you are proposing that the appData is *opaque to the CDM*, then things might be different. i.e. the appData would be an opaque BLOB that the CDM is supposed to include within the license request message (protected by whatever mechanisms the CDM uses to protect its messages). Is that what you meant ? I'd have to think further about that.

[steele] I am not sure I see the distinction here. I can already append opaque data to the initData passed in createSession from the client app. However I would have to include additional logic in the client app to encode the opaque data in a way that key-system wants. With my proposal - any CDM (including ClearKey) can use the information directly or encode it appropriately for the key server without having the encoding logic in the app itself.

The distinction is between
(a) the CDM expects appData to be in a keysystem-specific format and can do whatever keysystem-specific things it wants with it
(b) the CDM is required to include the appData unmodified inside the license request and should not expect to be able to parse or understand the contents

In (a) the appData is keysystem-specific and requires keysystem-specific code in the application to create it
In (b) the appData is application-specific and keysystem-independent - we are just using the keysystem messaging as a convenient secure channel between client application and server



Regarding TLS, we have been working in the W3C WebCrypto WG to define cryptographic primitives and key storage such that you can build lightweight secure application protocols in Javascript without TLS.

[steele] I considered that option, however it does not address my concern about additional encoding logic. I would prefer not to burden the app developer with writing security protocol code in their app.

I could solve this in a variety of ways, e.g.:
* built security protocol logic into every app that supports my CDM
* allow the CDM to bring up its own user interface for gathering information
* allow the CDM to snoop into the DOM and pull out predefined fields

All of these seem more intrusive and less developer-friendly than what I have proposed.

I'm not sure why the first option above is not developer-friendly. Every app needs some kind of authentication and authorization logic. How secure that needs to be depends on the app. It was an explicit decision in the EME architecture to leave that to applications rather than have the keysystem take that on because there is nothing special about authentication and authorization (in terms of IPR and other controversial issues) that justifies them being delegated to the "black box" of the CDM.

…Mark


Joe


…Mark

On Oct 16, 2012, at 9:36 AM, Joe Steele wrote:

Although the specific use case I cited was for authentication, this could be used by an application to include any additional information for the key system to use in subsequent key requests while not relying on TLS channel security.

I have some specific reasons for not wanting to rely on TLS for this usage:
1. Establishing a TLS channel requires several back and forth messages, while a protocol that relies on known keys can be more succinct. This is a significant network scaling concern when you are talking about delivering millions of licenses (for example an Olympic event).
2. High-availability TLS endpoints are more expensive than the same server without TLS.
3. Relying on TLS requires that the root for the servers certificates be trusted on the client end. You have to purchase those certificates from one of a relatively small group of trusted vendors in order to be immediately compatible across a wide range of browsers, which introduces additional cost. Relying on an independent PKI infrastructure (while more difficult to setup) allows for some additional scaling benefits.
4. Relying on the browsers trusted roots leaves the user (and the key system) vulnerable to TLS-proxy attacks (http://www.thoughtcrime.org/software/sslsniff/). Having a more limited set of trusted roots limits the effectiveness of these attacks.

I believe this change will make authors lives easier by allowing them to build high availability video applications while not limiting them to a single mechanism (TLS) for maintaining user confidentiality. This will also encourage them to write their UI in HTML as opposed to relying on browser specific behaviors/configuration for securing their information gathering.

I don't believe this would encourage any more fragmentation than will exist naturally. I believe a reasonable default behavior for clearKey would be to include the additional parameters in a JSON envelope along with the key request as you have indicated you are doing.

Joe Steele
steele@adobe.com<mailto:steele@adobe.com>

On Oct 15, 2012, at 4:19 PM, Steven Robertson wrote:

This seems like it would encourage fragmentation across key systems,
which would compromise the usability of the spec for authors.

I'm not sure I understand the reason authentication or other side
channel information couldn't be obtained through more standard means
(e.g. credentialed XHR or query parameters). Further, it seems that
this would not afford any additional protection against client-side
manipulation or forgery. The only effective difference between passing
information in the proposed manner and passing via standard means
appears to be that the former is proprietary to a particular key
system. Is there another motivation for this change which I'm not
seeing?

Our current prototypes have thus far been successful in remaining
format- and key-system-agnostic except in the places where such
parameters are directly required. We do this by wrapping all license
requests and responses in a JSON envelope on an HTTPS request that
provides a consistent, cross-environment, cross-key-system approach to
common tasks such as credential verification, descriptive error
signaling, and request retry. This has greatly simplified our
application infrastructure and license server interface. I would very
much like to maintain that simplicity, and I suspect that the proposed
change would lead us away from that.

On Mon, Oct 15, 2012 at 1:40 PM, Joe Steele <steele@adobe.com<mailto:steele@adobe.com>> wrote:
I reopened this bug a few weeks ago because I would like to see a mechanism
for passing application level parameters down into the CDM when the key
session is created.

As I said on on of the recent calls, my reasoning is that some CDMs may
transmit authentication/authorization data in-band (that is via CDM-specific
mechanisms).

An example of this would be:

<script>
 function handleKeyNeeded(event) {
   var video = event.target;
   var initData = event.initData;
   var appData = { username: "foo", token: "A53DF98700ABFE11",
sessionNonce: "DJKGDH+!9861XxbODY1287x===" };

   if (!video.keys)
     video.keys = MediaKeys("com.example.somesystem");
   if (!video.keys)
     throw "Could not create MediaKeys";

   var keySession = mediaKeys.createSession(mimeType, initData, appData);
   if (!keySession)
     throw "Could not create key session";

   keySession.onkeymessage="handleMessage(event)";
 }

 function handleMessage(event) {
   var keySession = event.target;
   var message = event.message;

   var xmlhttp = new XMLHttpRequest();
   xmlhttp.open("POST", "http://.../getkey", false);
   xmlhttp.send(message);
   var key = new Uint8Array(xmlhttp.response);
   keySession.addKey(key);
 }
</script>

<video src="foo.dash" autoplay onneedkey="handleKeyNeeded(event)"
onkeymessage="handleMessage(event)"></video>


The appData parameter would be optional and NULL by default. CDM's which do
not handle this parameter could simply ignore it if passed.
This is a use-case which would be used by at least one content protection
mechanism today, possibly more than one.


Joe Steele
steele@adobe.com<mailto:steele@adobe.com>