Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"tracked" sessions: when to persist "record of key usage" is not specified #82

Closed
ddorwin opened this issue Aug 27, 2015 · 10 comments

Comments

Projects
None yet
2 participants
@ddorwin
Copy link
Contributor

commented Aug 27, 2015

Pull request #54 added text to section 7.5.2, the Encrypted Block Encountered algorithm, that specifies modification of an entry of the "record of key usage". However, that record and the behavior around it is not specified. As has been previously discussed, there are specific implementation requirements in order for such records to be useful to the author. These should be specified.

The method that is technically possible for most user agents involves storing such records in (tamper-resistant) memory then persisting the record when the license/keys are destroyed.

Therefore:

  • The steps in 7.5.2 should have a Note to be clear that the data should not be persisted at that point.
  • The algorithms related to license/key destruction should be updated to include persisting the "record of key usage." I believe this includes the Session Close algorithm and the remove() algorithm.
@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Aug 27, 2015

Requirements on exactly how this is implemented arise from the fact that CDMs are subject to robustness rules. This applies to other aspects of EME as well but we have not so far discussed robustness in our specification. What should be the rule for deciding which robustness aspects we need to address in the specification and which we do not ?

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Aug 28, 2015

From previous discussions, I think we agree that:

  • The usage records must be persisted to be effective in handling some cases, such as non-graceful close.
  • Without certain platform capabilities, persisting the records at the wrong time leads to an unusable implementation.

This issue is requesting definition of the observable behavior in the algorithms as well as any additional information (not covered in the algorithms) necessary to ensure an implementation is interoperable and usable. This does not prevent implementations from using platform capabilities to enable greater protection (“robustness”) of the storage or optimizations, as long as the observable behavior is consistent with the algorithms.

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Aug 28, 2015

I agree the observable behavior should be clear and I'll review the current text in the light of the points above (next week).

However, I'm still stuck on how we should decide which robustness aspects to address and which not. For example, with persistent sessions, CDMs can support features such as play counts or license expiration (e.g. 24 hour rental) for offline playback which typically, in practice, require certain robustness features of the persistent store and clocks, but we do not address this at all in our specification. The presence or absence of the robustness features does not affect the behavior on the API. The level of robustness required is up to service providers. Should we address all this too ?

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2015

We discussed this on the telco [1 and there's reluctance to go down the path of specifying requirements that are derived only from robustness rules - this could be a can of worms.

In this instance we should specify that the record of key usage is persisted at the latest when the keys are destroyed. This is sufficient to define the observable behavior.

[1] http://www.w3.org/2015/09/01-html-media-minutes.html

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2015

Actually, we explicitly state that the presence of a persisted record of key usage indicates that the keys were destroyed. So, in terms of defining observable behavior, we should require that persistence occurs at the time the keys are destroyed.

The approach of persisting to secure store during playback is an implementation approach with the same observable behavior.

mwatson2 added a commit to mwatson2/encrypted-media that referenced this issue Sep 3, 2015

mwatson2 added a commit to mwatson2/encrypted-media that referenced this issue Sep 3, 2015

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Sep 3, 2015

#89

@ddorwin

This comment has been minimized.

Copy link
Contributor Author

commented Sep 10, 2015

I agree with the comment before the pull request, and #89 captures this in prose. We might want to add “securely” to “persisting” in the Note as a hint at the issues I mentioned in the original description.

In addition, the algorithms should be updated such that "persistence occurs at the time the keys are destroyed" as I suggested in the last bullet of the original description. (See also the discussion of prose vs. algorithms in #83.)

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2015

We can update the algorithms for the times the keys are explicitly destroyed but there are other times keys are destroyed where the record of key usage may still be persisted.

Regarding "securely", everything that is persisted (e.g. licenses) in practice needs to be persisted "securely". As per the comments above, I don't think we should go into that since exactly what "securely" means is very complex.

mwatson2 added a commit to mwatson2/encrypted-media that referenced this issue Sep 10, 2015

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Sep 10, 2015

I've updated the PR to be explicit in the algorithms about when the record of key usage is stored. This happens in the remove() method and the Session Close algorithm. I noticed that the Session Close algorithm did not explicitly say in its procedures that licenses and keys would be destroyed (it was just in the prose) so I have added that as well.

@ddorwin ddorwin modified the milestone: V1 Oct 20, 2015

@mwatson2 mwatson2 added the blocked label Oct 27, 2015

@mwatson2

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2015

Per comments on PR#89 we are waiting for Issue #80 to be resolved before resolving this one.

mwatson2 added a commit to mwatson2/encrypted-media that referenced this issue Nov 5, 2015

@mwatson2 mwatson2 removed the blocked label Nov 5, 2015

mwatson2 added a commit to mwatson2/encrypted-media that referenced this issue Nov 16, 2015

@mwatson2 mwatson2 closed this in afe53ab Nov 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.