[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 #60 from Joe Steele <steele@adobe.com> ---
(In reply to Joe Steele from comment #56)
> (In reply to Ryan Sleevi from comment #54)
> > (In reply to Mark Watson from comment #50)
> > As for the claims of SSL adding additional overhead or latency, I would
> > encourage members to read
> > http://tools.ietf.org/html/draft-mattsson-uta-tls-overhead-00 (for which an
> > update is already being prepared), that looks at the practical real-world
> > overhead and shows that it's virtually non-existent.
> 
> The overhead is not zero. And when you are having large numbers of
> transactions compressed into a small window the overhead can have a
> significant impact. Not to mention that SSL introduces additional failure
> modes as Mark mentioned earlier. 

I just read through this draft. It seems very thorough and I can't dispute the
claims made. However -- I still don't think this is a good argument for
requiring TLS on these APIs.

This quote in particular -- from the end of the draft:

   For everything but very short connections, TLS is not inducing any
   major traffic overhead (nor CPU or memory overhead).  Server people
   from Google Gmail has stated that "TLS accounts for less than 1% of
   the CPU load, less than 10 KB of memory per connection and less than
   2% of network overhead".  Main impact of TLS is increased latency,
   this can by reduced by using session resumption, cache information
   closer to end users, or waiting for TLS 1.3.

The key requests made by some DRMs fall exactly into this category of "very
short connections". One packet out, one packet in. The overhead of negotiating
an SSL channel (which may ultimately add nothing to the security) can be almost
100%. Even if we wait for TLS 1.3 as suggested. 

The increased latency mentioned could definitely cause a problem for media
streams which are highly time sensitive - e.g. live sporting events. However
the mitigations suggested do not seem like they would be effective for one-off
connections to CDNs. This seems like it will require fairly major
infrastructure improvements before it will be at the point that we can discard
HTTP completely. 

Let's leave this proposed mitigation for a later version of the spec where the
choice is not as painful.

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

Received on Thursday, 21 August 2014 22:20:15 UTC