[Bug 26332] Applications should only use EME APIs on secure origins (e.g. HTTPS)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332

--- Comment #127 from David Dorwin <ddorwin@google.com> ---
(In reply to Henri Sivonen from comment #123)

Putting user agents that do the right thing for their users at a disadvantage
is definitely something we want to avoid. I raised this concern in the last
paragraph of comment #0 as well as later.

Anne's proposal in comment #125 seems like a reasonable approach to avoid this.
As Domenic noted in
http://lists.w3.org/Archives/Public/www-tag/2014Oct/0100.html, this could even
be testable ahead of time.

> Since I care about the privacy properties of EME in general and
> EME-in-Firefox in particular and I expect Chrome, IE and Safari to keep
> shipping without an https-only restriction, I think it's not good enough to
> to say that the spec restricting things to https only mitigates the privacy
> problems if https-only isn't actually what gets shipped. This is why I'm
> interested in finding ways to address the privacy issues without https, even
> though in principle, it's not cool to try engineer for https avoidance and
> it's not good to be seen as trying to engineer for https avoidance. I then
> want to (try to at least) push those mitigations to be real in what Mozilla
> ships. I also hope that documenting solutions that don't require https in
> the spec helps improve the situation for users of other browsers, too.

I expect that these user agents will follow the entire spec when they update
their implementations to a future version of this spec. The same would apply to
any other mitigations added to the spec.

I agree that we should work to address privacy and security issues in other
ways as well. I welcome input and proposed text on other solutions/mitigations.
There are some open bugs on these issues, but feel free to open others.

> Is worth noting that restricting EME to https origins is not a silver
> bullet. In particular, it doesn't address privacy problems related to what
> the site at the other end of the TLS pipe learns. That is, mandating https
> does not remove all the problems that affect permanent Web-exposed unique
> identifier poses.

Agreed. We should address these issues as well. Bug 27165 and bug 27166 cover
similar issues.

> Also, restricting EME to https origins the way Chrome has restricted Web
> Crypto to https origins—i.e. requiring the origin that calls the API to be
> an https origin—is not good enough to address the concerns that Ryan raises
> in https://twitter.com/sleevi_/status/526586427656507394 and in
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332#c114 . The MITM would
> inject an https iframe into http pages such that the https iframe loads from
> a MITM-controlled server that has a legitimately obtained certificate and
> serves a JS app to talk with a MITM-controlled key server that sees the
> identifier exposed by the key system. To make the DRM identifiers
> unavailable to an active MITM (unless the MITM forges certificates), the
> https-only restriction must apply to all origins in the whole chain of
> browsing context from the browsing context using EME to the top-level
> browsing context. In other words,
> https://dvcs.w3.org/hg/html-media/rev/896eb33b68a2 does not actually address
> the threats that Ryan has brought forward.

Do you have a proposal for how to modify the existing text to address this
concern?

> On the other hand, if the spec required the sort of identifier and
> associated storage partitioning that Mozilla is on track implementing, i.e.
> partitioning by all of:
>  1) Device-unique bits.
>  2) The origin using EME.
>  3) The origin of the top-level browsing context.
>  4) A randomly-generated salt associated with the pair of #2 and #3
> and persisted until the user requests the salt be forgotten.)
> ...node locking would still be accomplished thanks to #1, but tracking
> across sites would be prevented and the user would have the opportunity to
> cause a discontinuity in tracking on a particular site.

Please file a bug to add normative text around identifiers. If it includes
proposed text, even better.

> If the spec further required the key system to encrypt messages such that
> the identifier is only visible to the key server, in terms of the id
> exposure, the result would be close (equivalent even?) to the https case (as
> currently written without the requirement for the whole browsing context
> path to the top-level to be https-only) as far as the threat of a key
> server-operating active MITM who injects EME-using iframes that connect to
> the MITM-operated key server goes.

You could file a bug for this too. I'm not sure what the normative text would
look like.

> P.S. Regarding cookie equivalence: If cookies were designed today, they'd be
> at minimum origin-scoped and possible https-only. Arguing mere cookie
> equilavence risks falling into the pattern that DJB characterizes as arguing
> against encrypting SNI because DNS traffic is unencrypted and arguing
> against encrypting DNS traffic because SNI is unencrypted.

For reference: Similar points about cookies has also been made in comment #47
and http://lists.w3.org/Archives/Public/www-tag/2014Oct/0082.html.


(In reply to Henri Sivonen from comment #126)

> I think exposing a permanent or origin-independent identifier to the other
> end of the TLS pipe would be a problem still, so I still think Mozilla-style
> partitioning of the CDM identity should be recommended even with https.

I agree that this is still a problem we need to address. See above.

> I think an https goal should not be allowed as an excuse not to
> recommend how equivalent or almost equivalent privacy properties could be
> achieved on the Key System layer.

I don't think anyone has argued that. Authenticated origins provide important
security and privacy properties, some of which cannot be obtained in other
ways, but the security and privacy concerns are extensive (as demonstrated by
the current considerations sections) and will require other solutions as well.
If you have specific concerns and/or solutions, please file bugs.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 30 October 2014 16:57:34 UTC