Re: Resolving issues around avoiding key requests

Replies inline —

> On Aug 2, 2015, at 9:09 PM, David Dorwin <ddorwin@google.com> wrote:
> 
> I have provided specific comments on the three issues inline. To summarize, I believe 52 (removal of a single word) depends on 41, resolving 41 should also consider 53, and that 53 requires a significant amount of work to develop a consistent, cohesive, and interoperable solution.
> 
> No new information has been provided that demonstrates that inclusion of these features - in an interoperable and consistent manner - is certain or that such resolution of the issues is trivial. Given the finite cycles of the editors, my recommendation is to continue to focus on facilitating interoperability for the existing feature set and resolving issues that affect many/most authors and implementers and block LC/CR.
> 
> On Thu, Jul 30, 2015 at 11:07 AM, Joe Steele <steele@adobe.com <mailto:steele@adobe.com>> wrote:
> There are three open issues relating to keys being provided in a manner that may allow key requests to be avoided. I am listing them below.
> Please review all three issues carefully and respond to this thread with your opinions and questions.
> 
> Issue 52 - Remove reference to keys in Initialization Data definition
> https://github.com/w3c/encrypted-media/issues/52 <https://github.com/w3c/encrypted-media/issues/52>
> 
> The addition of keys to the list of restricted data in the initData was made without any group input as far as I can tell. This restriction flies in the face of the CENC specification which members of this group agreed to support. I believe that the burden should be on the author of this list to provide justification. In the F2F meeting the justification offered for this restriction (as I recall) was that this would lead to an interop problem. I disagree with this and say that this can only lead to an interop problem if in fact those keys are used by the CDM directly, which *could* require the algorithm changes proposed in issue 41. However it does not *necessarily* lead to an interop problem. This edit is also required to allow for the DRM specific key metadata specified by CENC. I believe this issue can be resolved independent of issues 41 and 53.
> 
> Some corrections:
> As I have repeatedly explained, adding the word "key(s)" to the definition was not a change in behavior; it made the definition consistent with the algorithms, which provide no mechanism for extracting keys from Initialization Data. Allowing keys (other than as a detail of the opaque blob to be sent to the license server) would require defining the extraction and processing of such keys (Issue 41).
I believe that when you wrote this text, you extrapolated based on the security related discussion and on the key delivery mechanisms you are most familiar with. However not all of this change had the consensus of the group. In particular, adding “keys” to this list of restrictions did not have the discussion it required. I do not believe that is in dispute and therefore that particular change should be backed out. Then then we can have the discussion starting with why you believe it is justified to *add* this restriction.

I don’t believe making this change *requires* the changes in 41. I believe the changes in 41 should be made in any event, but they are independent. As you just pointed out, the keys may be part of the opaque blob sent to the license server.

> Just as MSE supports a subset of MP4 streams to ensure compatibility with the algorithms and increase the likelihood of interoperability, EME supports a subset of possible CENC streams with a preference for openness and interoperability. In other words, EME is not a superset of CENC.
In no way am I implying that EME is a superset of CENC. I am saying that we should not arbitrarily restrict CENC content simply because the PSSH information (which is DRM specific) happens to include keys.

> 
> Questions:
> Could you clarify why you believe that keys in initData is currently supported by the spec? Specifically, how/where in the application flow/spec are they used?
These keys if present would be a Key System specific detail and not specifically reflected in the spec. Much like the platform keys and hardware keys discussed in earlier emails. The presence of them is outside the scope of this spec. The usage of them only needs to be reflected in the spec to the extent that it impacts the algorithms.

> Regarding "this can only lead to an interop problem if in fact those keys are used by the CDM directly": Since “DRM specific key metadata” is opaque - and in Adobe’s case encrypted - I believe only the CDM / license server can access such keys. Am I missing something? How would such keys be used indirectly by the CDM or by some other entity?
Those keys could be indirectly used by the CDM if they are sent as part of a key request to a key server for further processing, before being delivered in a key response.

> 
> Issue 41 - Update algorithms to reflect keys being provided in the Initialization Data
> https://github.com/w3c/encrypted-media/issues/41 <https://github.com/w3c/encrypted-media/issues/41>
> 
> The justification for this proposal is that requesting a key from a license server is expensive. If it is unnecessary to request a key because the keys are already available to the CDM in a manner that complies with all other security/privacy restrictions in the spec, I believe the spec should support not issuing a key request. It has been argued that this will lead to interop issues. I would point out that protocol and policy differences can already cause key requests to happen on a different schedule between Key Systems. This is not fundamentally different and I do not believe that this change will cause much if any additional work for developers. This is blocked by issue 52.
> 
> As you note under Issue 53 below, the spec does not currently allow use of keys not present in an active session (other than keys that are part of the DRM protocol, such as platform or individualization/provisioned keys). Thus, there is currently no mechanism for "the keys [to] already [be] available to the CDM." I don't oppose such a concept, but I think it requires careful consideration and design to maintain consistency with the rest of the spec as well as related features, such as issue 53.

Key being delivered in the metadata is one mechanism that the spec currently forbids. I would like to correct that.

But this situation can also occur if keys are delivered to one session which could be used to satisfy a subsequent key request in another session, while that first session is still active. In that scenario, the server knows based on the original license request that multiple keys will be required (perhaps because they belong to a set of related content) and delivers those keys in addition to the requested key. When later key requests are made, those key may already be available from the previous response.

> 
> This is blocking issue 52 for the reason explained in that section above. (In reality, they would likely be resolved together.)
> 
> Issue 53 - Allow for long-lived key encryption keys (aka "master" keys) to increase performance
> https://github.com/w3c/encrypted-media/issues/53 <https://github.com/w3c/encrypted-media/issues/53>
> 
> The justification for this proposal is supporting increased performance for DRMs that can avoid additional license requests. Most if not all DRMs already support some type of key chaining, where a key is either generated on the client or delivered to the client and then that client key is subsequently used for decrypting the content keys provided via key server responses (aka licenses). This chaining today is invisible to the application and is considered “out of scope” for this specification. I am proposing that we bring a variety of key chaining in scope, specifically when more than two keys are involved in the chain for performance reasons. The main problem with the current text is that it assumes that keys acquired during a session will go away once the session is closed, even when there are other active sessions on the same MediaKeys object. This would need to change to make retaining master keys across sessions compliant with the spec. This is blocked by issue 41, since using a master key would imply that a key request is not required in some cases.
> 
> I have ideas for how this might work, but they involve significant changes/additions to the spec, including new session type(s).

Agreed. This is definitely a more controversial change and requires a lot of thought. I am not sure how a new session type would help, but I am eager to hear more.

> 
> Joe
>