[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 #68 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Joe Steele from comment #64)
> None of this efficiency makes any difference in this case. The CDM is
> constructing the request - which in our case is a single packet. The
> application can use any mechanism to send it it likes, but HTTP is good
> enough in our case and quite efficient. TLS would be overkill and not add
> anything to the security. 

You cannot have your cake and eat it to. You just described the overhead as
being one packet in, one packet out, but that's clearly not the case. Just
because the CDM constructs the request does not require, as you incorrectly
suggested, that a UA establish a new connection.

Note that you're also firm in the territory of non-guaranteed behaviour when
you say "HTTP is good enough in our case". One, UAs can and will disagree with
that assertion for *your* protocol, and two, not all CDMs may be able to
implement that.

In the absence of hard guarantees about the security properties, requiring TLS
is to ensure that even at a baseline, the security properties are the minimal
acceptable level, and in a way that's consistently implemented (ergo,
interorperable)

> I do not mean that. I am referring to the latency that will result from the
> CDN delivering the media stream having to re-encrypt each media segment for
> delivery.

And, as the IETF UTA WG has shown, that latency is effectively non-existant in
the whole.

> No. The overhead in my case in particular is large if TLS is used. Less with
> the better algorithms described in that document, but still large relative
> to using HTTP. 

And yet the real world evidence - and the draft mentioned - show this is a
claim without merit or fact. You can keep repeating it, but it doesn't make it
any more true.

> But you have not seen them all. And yet you are proposing to restrict all of
> them based on the subset you have seen. 

Correct. The fact that most of what we've seen - from members of active in this
very discussion - is that it fails to meet the minimum bar of security. That a
hypothetical CDM might exist which preserves privacy sufficiently is an
interesting theorhetical discussion, but the practical reality is few do, and,
more importantly for this discussion, have no such guarantees or requirements
of continuing to do so.

Because, as Glenn so decisively puts, that this WG will not, in any way shape
or form, place any such requirements that the CDMs implement such basic levels
of security, it becomes necessary to place requirements on how CDMs are used,
since we cannot place requirements on the CDMs themselves. 


> Your assumptions seem to be that all DRM protocols are home-grown and not
> based on robust well analyzed protocols. You have not offered any proof of
> this other than your experience. 

The proof is in the very fact that Mark Watson has repeatedly told the W3C in a
variety of forums that the protocols employed CANNOT be discussed in an open
context.

If they could, we would and could have a unified CDM architecture and stop
faffing about with different licensing protocols.

This inherent opaqueness is a formal guarantee that there lacks the body of
evidence. If you want to establish that the DRM protocols employed by CDMs -
the ones that have significant access to long-term tracking identifiers and
which, in the vast majority, actively employ them without any of the
mitigations *suggested* in this document, then I think the burden of proof
rests solely with you.

> Nice. You try to refute the argument and then say "let's take this
> elsewhere" implying I would be churlish to respond. Well played sir. 
> 
> I am sure when you read the article you realized the implication is that the
> public CANNOT audit the behavior of CAs to any reasonable degree. And what
> is worse, even when those CA's have been proven to be bad actors, we can't
> always move away from them because they are indeed "too big to fail".

I'm saying that a discussion of the CA ecosystem is entirely inappropriate for
this bug. That you're using this as a means to divert the discussion from the
more tangible and real security aspects is extremely unfortunate, but equally
inappropriate.

I'm more than happy to describe to you exactly how the world that Moxie
described THREE YEARS AGO is not at all the world we live in, nor the world we
will, but this bug is an entirely inappropriate forum and venue for it. I'm not
at all casually dismissing Moxie's argument - I think there were many apt
observations. But those were old observations that barely held then and
certainly do not hold now, so referring to them as somehow proof that TLS is
insecure is simply incorrect.

(In reply to Glenn Adams from comment #67)
> (In reply to Ryan Sleevi from comment #61)
> > Your CDM does not have a network connection
> > (normatively), it defers to the UA to mediate all key exchanges.
> 
> From what normative text do you derive this statement?

Merely that CDMs are not normatively guaranteed to have a network connection,
not that they are normatively prevented from having one (though they should be,
and in practical implementations, are).

They are, however, normatively guaranteed to have a means of having the UA act
on their behalf with respect to the key exchange.

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

Received on Friday, 22 August 2014 03:56:36 UTC