Re: [EME] Updated proposal for secure proof of key release

On Jan 17, 2013, at 9:14 AM, David Dorwin wrote:



On Wed, Jan 16, 2013 at 4:57 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Jan 16, 2013, at 3:40 PM, David Dorwin wrote:

I filed a couple bugs to track some minor issues with the existing spec. Comments inline.

On Wed, Jan 16, 2013 at 1:45 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On Jan 16, 2013, at 12:20 PM, David Dorwin wrote:

Hi Mark,

Comments and suggestions inline.

David

On Tue, Jan 15, 2013 at 9:36 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
Here are some additional changes which I think are required to implement David's alternative proposal for [1]

Address [2].

To Section 1.2.3 (SessionID):
- To "If session IDs are supported, a new one will be generated each time createSession() successfully creates a MediaKeySession" add "for a new key session."
- Change "although the CDM may retain them for longer periods" to "although the CDM may retain key sessions and their associated IDs for longer periods.".
- Change "If secure proof of key release is supported each Session ID shall be unique within the origin." to "If the CDM retains key sessions across browsing sessions then each Session ID shall be unique within the origin."

I suggest changing  "If" to "When". If a CDM supported both retained and unretained sessions, it does not always have to use unique IDs.

Ok.



To David's createSession() proposal (see [1]):
- To "Let key request be a key request generated by the CDM using initData, if provided" add "or null if no key request is generated."

So keymessage's message attribute can be null? That affects the event definition (3.1) and seems undesirable. My proposed patch just says a response is generated and assigned to the message attribute. That can be an empty array in the key release case. Do we really need to support null or specify what the value is?

Empty array might work.

If we say that createSession() can retrieve an old session, and we say this is generic, in support of "whatever capabilities CDMs want to offer", not just specifically for secure proof of key release, then there is the case of a session being retrieved in a state where no messages need to be sent. For example a persisted session that already has an unexpired license matching the supplied initData. But we need to generate some kind of event to indicate when the sessionId has been assigned. A null message seemed reasonable for this.

Sending keymessage to indicate "the CDM did what the app asked but has nothing to send to the server" seems useful and null/empty seems like a good normative definition for this. The only question is whether to use null or an empty array. If an app gets a null value, it may not handle an exception and stop working. If it gets an empty message and sends it to the server, it would seem things have a better chance of succeeding and the server can detect the issue. I'd like to hear from others that have more experience with these types of issues and API designs. In the end, it's a small issue. I opened https://www.w3.org/Bugs/Public/show_bug.cgi?id=20689 to track this discussion.

- To "Note: cdm must not use any data, including media data, not provided via initDate" add "or already present in the cdm".

This is a note about creating the key request. Since one is not created in your use case, I don't think this applies. More importantly, such a change has much larger implications than key release. You can instead add "to generate a key request" to the current text if you want.

Hmm - I didn't read carefully enough where is refers to "key request". If we're making this generic, shouldn't it just be "key message" ? In the secure proof of key release case, where I retrieve a session related to a deleted key, the message will be the secure proof of key release message.

The purpose of this text was to enforce that the information about the media that is used to generate a key request be provided via the initData parameter. This doesn't necessarily apply to other uses of createSession(). Thus, by adding "to generate a key request", we still enforce this for key requests while lifting the limitation for other uses.


- Add to the above note: "The CDM may use pre-existing session data that matches the provided type and initData and that is not already associated with a MediaKeySession to initialize the session."

This seems pretty confusing. Is it necessary? Initializing a session is key system-/CDM-specific and nothing prevents the scenario in the proposed text.
As mentioned above, the existing normative note is specifically related to generation of a key request, so I definitely don't think they should be folded together.

I think we need to say something too explain how you can retrieve old sessions in a CDM-independent way.



New FAQ and answer:

"Is secure management of the entire key lifecycle supported ?

Yes.

If a CDM implements the capability to provide a secure proof of key destruction (i.e. a signed attestation from the CDM that a given key has been destroyed), this capability may be exposed by generating a keymessage event when the key is destroyed, containing this attestation. The CDM should persist a record of the session and the key destruction, in case the keymessage cannot be delivered for any reason, for example network loss or inability to deliver messages during page close. This persisted record should be removed when an acknowledgement of the secure proof of key release is received through an update() method. MediaKeySessions associated with such persisted sessions could be retrieved at a later time (e.g. after page unload and later page load) using the createSession() method with null type and initData which implicitly match any persisted session for the page origin."

I think null type is a strong and potentially generally useful value that should not be dedicated to key release

I'm not suggesting it's dedicated to key release. It would match any persisted session, whatever state that is in.

Okay. My statement still applies to "persisted session". I think the use of "null" would have to really stand out as "of course, that makes sense."
As it stands, we allow null but don't really have a use case and it's basically there for key system-specific use. Maybe we should make it a required parameter. I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20691.

nor have its behavior defined in a FAQ or other non-normative text.

Actually it should be defined normatively that "null" matches everything, rather than nothing.

|type| is intended to tell the CDM how to interpret |initData|. I'm not sure "everything" makes sense in this context.

I agree 'null' isn't ideal, but I would still like to have a defined way to retrieve an arbitrary pre-existing session, since that's the missing generic capability

I'm not sure we need a way to "retrieve an arbitrary pre-existing session". That is a really wide scope for which we can't possibly foresee all the scenarios it might affect. Even type = "persisted" might be too generic. Some key system might have another reason to persist sessions and a defined generic capability could cause ambiguity for apps. I think the class of sessions you really want to be returned is "persisted key releases" or "persisted inactive/closed sessions".

needed to give proof of key release the same status as heartbeat etc.

Can you clarify?

I thought your proposal was that we would tweak/modify the existing general purpose text so that secure proof of key release became something which could be implemented by CDMs without special CDM-specific logic in the client application - in the same way as heartbeat can. This was the justification for removing the secure proof of key release section.

To do that, we need sufficient generic capabilities in the main text that the implementation of secure proof of key release doesn't seem like a hack. Having the CDM decide to send messages and expect response at the time of its choice (as for heartbeat) seems completely natural. But expecting applications to know a CDM-specific incantation to retrieve persisted sessions seems like a hack.


I was planning to remove the heartbeat text since it just describes a policy and can be implemented entirely within a key system without adding any special logic to the application.

I think this illustrates why, with the existing text, secure proof of key release is different in character from heartbeat: it does require a normative capability to retrieve persistent sessions.

I don't think the "null" thing is particularly elegant. We could consider extending the createSession call with an enum for the kind of operation expected (new session, retrieve existing session etc.). If you think that a specific value is needed to retrieve "release key" sessions specifically, then I think we need to return to the model where we do include secure proof of key release as an explicit section. It could be a lot shorter now, as we don't need to duplicate the createSession() algorithm and I agree we could restrict it to describing how the persisted released key sessions are retrieved and not go into the other messaging of CDM procedure details.

…Mark


Do you have any other suggestions ?



(Key systems may wish to use it for something else.) Is there any reason not to use type = "keyrelease" from your original proposal?

The original proposal was normative. I agree that we should try and find a way where secure proof of key release is not specified normatively, but can be built using the generic normative capabilities, in the same way as heartbeat etc. But that means we need to define those generic normative capabilities - specifically the retrieval of pre-existing sessions, which is what I was trying to do above.

Certainly a CDM "can" provide any capability it wants - but I think we need at least the basic concepts in the API in order for people to understand how the capability makes sense in the context of the API and to ensure some commonality across implementations. Otherwise it just looks like secure proof of key release is a hack, not something which was considered as a reasonable capability to be supported in the API.


Minor note: "release" and "destruction" seem to be used interchangeably. Is that intentional?

No.




…Mark

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622

On Jan 15, 2013, at 8:03 AM, Mark Watson wrote:

I think we also need to address https://www.w3.org/Bugs/Public/show_bug.cgi?id=20622

I will provide text for the FAQ answer.

As for requesting old sessions, I think we need to explicitly introduce the idea that CDMs may persist sessions and so createSession() may retrieve a preexisting session based on the type and initData. If the provided type/initData match multiple pre-existing sessions, then any one is returned (and so if they are both null, than any pre-existing session is returned). We should also ask that a keymessage is always sent (even if it might be null) when the session is created so that the user script has some indication when the sessionId is assigned.

…Mark

On Jan 14, 2013, at 6:19 PM, David Dorwin wrote:

Mark and I discussed this and agree that we should try to reuse as much of the base algorithms as possible. Mark would also like a consistent way to retrieve saved key sessions and a FAQ answer. Therefore, I propose the following tasks for resolution for this bug:

  *   Generalize createSession() algorithm so proposed 4.5.1 is covered by it. There are a few statements that assume generation of licenses.
  *   Figure out where to document how to request old sessions, if supported.
  *   Add a FAQ entry about how key release could be supported, similar to the entry for heartbeat.

I’ve started working on the createSession() changes.

David

On Fri, Jan 11, 2013 at 6:10 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
Hi David,

Please see inline …

On Jan 11, 2013, at 10:07 AM, David Dorwin wrote:

Hi Mark,

The more I think about key release, the more I think it should not be included in the spec.

Key management, policies, message protocol & structure, and key-system or CDM-specific details have been intentionally left out of the spec. As an example, even the key replacement algorithm is not specified. Key systems are free to define protocols that include a variety of messages as long as they fit within the defined APIs (primarily update() and keymessage). Heartbeat, license renewal, key rotation, etc. can all be implemented within the existing framework but are not included in the spec.

The key release proposal does not require altering the existing APIs or the defined algorithms. It simply defines additional key management, policy, parameter values, and messages, all of which are key system-specific. As with the basic message flow, heartbeat, etc., I expect that key systems will eventually converge on a set of best practices, but these are not usually defined in a standards-track spec.

The proposal does expose functionality at the API level and it's not all just key-system specific.

Specifically, the concept of "sessions" and "sessionIds" is an API concept, not a key-system-specific one. We say that anything that goes on *within* a session is keysystem-specific. For example, the number of message exchanges, when they occur in the session, what they do in terms of keys etc. Heartbeat and key rotation are both examples of where - within a session - some keysystem-specific magic can go on.

But the notion of a session itself is part of our API. We define how you create them in a key-system-specific way. They're created from a keysystem-independent object (the initData - although within it there may be multiple keysystem-specific parts).

The key part of the secure proof of key release proposal is that it is possible, from outside any session, to retrieve information related to pre-existing sessions. We're adding a new way to interact with the CDM outside the context of a session. I don't see how we could do that within the existing API.


Finally are there implementors and CDM providers that intend to support this? Are there any content providers besides Netflix that intend to use it?

Those are good questions. If the answer to the first one is no when we get to the appropriate milestones in the specification work, we'll have to pull this out. Just like anything else.

I'm not really empowered to speak on behalf of CDM implementors, but I know that it's not pointless putting this in the specification now.

…Mark


I do not think a Working Draft should include a feature where the answer to the above questions is "no", especially when it adds non-trivial complexity to implementations.

Regards,
David

On Fri, Jan 11, 2013 at 9:10 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17199

An updated proposal is attached.

I'd like to propose that we include this text in the First Public Working Draft.

[It need not be Section 4, as written, since this interrupts the flow of the rest of the document. I leave it to David to suggest the best place for it.]

…Mark