Re: EME compatibility with existing DRM systems

On May 9, 2013, at 11:25 AM, Mark Watson <watsonm@netflix.com> wrote:

> 
> 
> On Thu, May 9, 2013 at 11:04 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
> 
> On May 8, 2013, at 9:02 AM, Mark Watson <watsonm@netflix.com> wrote:
> 
>> 
>> 
>> On Wed, May 8, 2013 at 8:45 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
>> 
>> On May 7, 2013, at 7:16 AM, Mark Watson <watsonm@netflix.com> wrote:
>> 
>>> Gilles,
>>> 
>>> The design of EME is that CDMs do not interact directly with content license servers*, but instead the license acquisition process is mediated by the application.
>>> 
>>> It's hard for the specification to *prohibit* such direct interaction, but you would likely find that a KeySystem that subverted the design approach would not be usable with most EME applications.
>>> 
>>> The reason for this design is to avoid the need for service providers - who must in practice support multiple DRM systems - to stand up multiple front-end license servers. Also it avoids the need to delegate application business logic such as user authentication and authorization to multiple DRM servers. These functions are properly handled by the application and the license server is used as a back-end server to provide licenses as required by the application.
>>> 
>>> As a result, existing DRM client components will likely need to be wrapped in some way to form an EME CDM. In the case of Marlin that you describe below it looks like you need to sign and encrypt the messages using the credentials you would otherwise use for securing the TLS connection.
>> 
>> That's understood. But doing that would defeat the purpose of the design of the Marlin MS3 protocol and its performance characteristics.
>> One of they key reasons why MS3 works over TLS the way it does is that it allows service providers to leverage existing software and hardware infrastructure to scale the DRM processing: TLS is a well known protocol, which has become a commodity. By choosing to leverage TLS as an authenticated, encrypted channel, service providers can delegate the crypto processing to off-the-shelf hardware and software solutions that implement plain-old TLS.
>> When using a model where message signing and encryption is done at a different layer (which, by the way, is done for other Marlin protocols, such as Marlin BB), all that off-the-shelf-ness goes out the window, and you're back to needing vendor-specific server software to implement the crypto processing of the messages.
>> 
>> Based on our experience with a large-scale service, the performance and scalability advantages of TLS for this application messaging would be rendered insignificant by the operational and architectural complexity associated with having multiple front-end DRM servers and managing the TLS credentials. We have also found TLS to be slow, significantly impacting stream start times. And that is without considering the security implications of tying the DRM message security to a single, unchangeable, solution (which is not really my area).
> 
> I think you may be confusing two very different things here. When you say: "We have also found TLS to be slow, significantly impacting stream start times", you are probably referring to using TLS for the stream data itself.
> 
> No, I am referring to using TLS for application control messages, including key delivery.
>  
> That is not at all what I'm talking about here. I'm talking about using TLS for key delivery only, not for the stream data. I explain this in more details in my second comment below.
> 
>>  
>> It would be a huge step backward if using EME meant not being able to take advantage of web-standard protocols like TLS. That would seem to be going in the exact opposite direction from what organizations like W3C usually strive for: more common standards, less vendor-specific technology.
>> 
>> You can certainly use TLS for your application messaging (from client JS to server), using XHR. What you can't do is bind this TLS connection to a DRM-controlled client credential (without some very special UA support). You'll need to do that binding in your CDM.
> 
> That's precisely the point: using TLS from the client JS to a server with XHR is useless for the DRM. What the DRM server needs is to authenticate the end point that will be receiving the key data sent in the HTTP-over-TLS response (what you call "do that binding in your CDM"). 
> Maybe I should explain a bit more what the normal sequence is like (not in the EME architecture, but in currently deployed systems):
> When the client app wants to play an encrypted asset (stream, file, or any resource that's encrypted), the content service provides the client (after any service-level authentication, like logging into a user account, etc.) with an HTTPS URL that points to a DRM server. The URL contains any data that the service needs in order to decide what key to send back as a response to the client (typically, you will find in the URL a content ID, some transaction context, sometimes an encrypted key or key seed, etc.). When the DRM server receives the incoming SSL connection request, it responds with a server-hello with the "client authentication" bit set, requiring the client to authenticate itself with an X.509 certificate. The DRM client (CDM/KeySystem here) uses its X.509 DRM credentials to respond. The server then verifies that the client's certificate is acceptable (i.e is under the PKI root for the DRM), and sends an HTTP response with a payload that contains one or more keys and associated key usage information. The server can do so because it knows that the recipient can be trusted to handle the key material in accordance with the DRM's compliance and robustness rules.
> 
> So, as you point out, what is needed here is "…to do that binding in your CDM.". But that's precisely what the current EME spec prevents
> 
> No, EME does not prevent it. Your CDM simply needs to sign your client->server message with the client private key and include the certificate chain with the message. The key would then encrypted with the client public key (an maybe signed with the server private key, if you need server authentication here).

Indeed, but that's not how TLS works. TLS is at the transport layer, not the message layer. My point here is that EME forces you to have a key delivery protocol that's message-based and precludes transport-level secure authenticate channels. It also seems that even for message-based protocols, the EME only allow one-shot message protocols, not multi-round (i.e there is only one Key Rest / Set Key per session).

>  
> : there is no way to have a direct authenticated TLS session between the DRM server and the CDM. Everything has to be proxied by the JS client, which precludes the use of TLS-based key delivery for DRM server scalability.
> Or are you suggesting that the EME model would allow someone "… to do that binding in your CDM"? If so, can you explain how that would work in the EME framework?
> 
> While I do understand that you have a preference for proxy'ing messages through a single entry point in YOUR service architecture because you find that it works well for you, that's not a reason to force all other services to adopt the same architecture. By preventing the Marlin MS3 model to work within the EME framework as is currently stands, the EME model forces a whole existing ecosystem to radically change the way it currently operates.
> 
> As I explained, you can implement the direct DRM client to DRM server messaging solution today without EME. EME is about enabling the architecture I described. If Marlin doesn't want to work with that architecture, noone is forcing it to.
> 
> An additional issue is that, unless I am mis-understanding, what you propose requires the CDM to have socket access - not just access to the browser HTTP stack. I say this because sending your request through the browser HTTP stack would require that stack to have access to the client credentials in order to establish the TLS connection. As soon as the client credentials are outside the CDM, your security is lost.

Yes, the CDM implements its own TLS client endpoint and therefore needs access to a TCP connection.

> 
> ...Mark
>  
> 
> -- Gilles
> 
>> 
>> ...Mark
>>  
>> 
>>> 
>>> I would note that content protection  systems that interact directly with license servers can be integrated into the video element without using EME at all. For example Apple HLS supports a form of content encryption which works in this way. The point of EME is to provide a uniform model so that applications can easily support multiple DRMs.
>>> 
>>> *Finally, for completeness, I should note that some DRM components perform a one-off installation/initialization interaction with a server maintained by the DRM provider, rather than the service provider. For this reason such components may need network access.
>>> 
>>> ...Mark
>>> 
>>> Sent from my iPhone
>>> 
>>> On May 7, 2013, at 5:35 AM, Gilles Boccon-Gibod <bok@bok.net> wrote:
>>> 
>>>> I found a video of a webinar given for the DTG group a month ago (http://vimeo.com/62269279), where the speaker gives an overview of the Encrypted Media Extensions.
>>>> There is one question that came up during the webinar regarding whether a Key System implementation is "allowed" to interact directly with a DRM server, without going through the user agent and application with a keymessage event.
>>>> The speaker's response was that he wasn't sure whether it was specifically forbidden or not, but that he couldn't see why it would be needed.
>>>> He also mention in the talk that one of the goal of the EME spec was to at least allow existing DRM systems to be supported through the proposed architecture.
>>>> So I'd like to explain a concrete specific case for the Marlin DRM system where the current EME architecture would be suboptimal, or at least require an implementation to "cheat" a bit with regards to the intended use of the keymessage/addkey workflow, which assumes that the communication between a Key System and DRM servers can always be intermediated by the application by passing it a keymessage to forward to the server and having the application, then, relay the response in the addkey() call.
>>>> In the lightweight, "on-demand", mode of Marlin, called MS3, which is often used when there is no persistent license delivered (a non-persistent lightweight license is sent back to an authenticated client, just for use within the context of a streaming session), the client needs a direct, non-intermediated, communication with a server.
>>>> For scalability reasons, the protocol between the DRM client and the server is based on a mutually-authenticated TLS session, not on a signed/encrypted data payload that can be relayed (like a SOAP message could be in the case of PlayReady for example). So there's no keymessage that could be created by the Key System. The Key System must have a direct TCP connection with the DRM server in order for the TLS handshake to be done, and the response to be protected, end-to-end, from the server back to the DRM client.
>>>> For Marlin MS3 to be used within the EME framework, I imagine that one could circumvent the intent of the keymessage/addkey pattern, and pass in the addkey() response (or the InitData of the createSession call) a payload containing the URL of the DRM server which the DRM client must talk to, and that the DRM client would simply go directly to the DRM server, bypassing the application. That does not sound very clean.
>>>> 
>>>> I'd love to hear what people on this email list think about this.
>>>> 
>>>> Regards,
>>>> 
>>>> -- Gilles
>> 
>> 
> 
>