Re: [rtcweb] No Interim on SDES at this juncture

[Hadriel Kaplan <[e-mail]>]

On Jun 20, 2013, at 4:58 PM, Roman Shpount <[e-mail]> wrote:

> Not to play devil's advocate, but how is it any different then arguments to support plain RTP? All the same things apply to RTP. On top of this SRTP is no more secure then plain RTP when communicating with a server over plain HTTP or communicating with untrusted server over HTTPS. If we decided that RTP is unacceptable from security point of view, then how is SRTP acceptable?

I'm operating under the assumption we would only allow the Browser to use SDES if and only if it is also using HTTPS to the web server.  And I'm operating under the assumption that all browsers still MUST offer DTLS-SRTP, and choose it instead SDES if they receive such an offer.  

In such a model, any two browsers do DTLS-SRTP to each other unless the web-server/JS is malicious.  Ergo, unless the web-server/JS is malicious, only calls to/from a gateway use an SDES key.  The SDES key isn't sniffable on the browser-server HTTPS portion.  Obviously it's sniffable beyond the web server, if it gets sent in the clear somewhere else.  But we know that will also happen even with DTLS-SRTP, because the gateway will terminate DTLS-SRTP and use SDES or plain RTP on the other side.  So we're not losing anything.

So... in theory the danger is relegated to the malicious web-server case.  But a malicious web server can get your media anyway, even with DTLS-SRTP, because it can simply direct you to its own "gateway" to terminate DTLS-SRTP and record the media.  There is no practical way to prevent a malicious web-server from getting your media, no matter what we do, for common every-day users.

Frankly with a malicious web server you're screwed in so many other ways anyway, that making it just slightly harder for it to get your media is like putting on a scuba drysuit when jumping into a pool of molten lava.  Yes, you'll live for some fraction of a millisecond longer.  And then what?

-hadriel