Re: [rtcweb] A compromise for SDES

[Hadriel Kaplan <[e-mail]>]

On Jul 17, 2013, at 4:48 PM, Matthew Kaufman (SKYPE) <[e-mail]> wrote:
>> Given those personal feelings, I didn't much care either way, so long as a
>> decision was made - although I still preferred having SDES to avoid the early
>> media clipping problem.  So when I was going to present on this topic back in
>> the Vancouver meeting, my last slide basically said: "If we support SDES and it
>> turns out later we were wrong, we can always rescind it".  This was based on
>> the notion that browsers get updated all the time, especially for security
>> issues.
>> 
>> But later it occurred to me that's actually the Achilles' heel of supporting SDES
>> in WebRTC, for those of us wanting to gateway this stuff to SIP.  Imagine if it
>> turns out we were wrong, and some expected-or-unexpected vulnerability is
>> exploited against some large WebRTC service provider, and makes the
>> news/slashdot.  Browser vendors would instantly have new code removing
>> SDES support, and browsers in devices would be updated virtually overnight -
>> some users may take a long time to upgrade their specific browsers on their
>> specific devices - but many of them would do so within days.  That would be
>> untenable for a WebRTC service provider. 
> 
> I can't imagine such a scenario that couldn't also happen with DTLS-SRTP, especially DTLS-SRTP + EKT.

Yes, I considered that as well - but if there's only one key-exchange mechanism, and it's the one used between browsers and everyone, then even the browser vendors wouldn't want to update the browsers in such a way that it's removed overnight.  They'd be braking media interop even between browsers.

For example, assume we only have DTLS-SRTP as MTI and some security vulnerability is discovered for it, which some new thing called "ETLS-SRTP" fixes.  They couldn't just remove DTLS-SRTP in favor of ETLS-SRTP overnight; they'd have to support both for some transition period - a period only constrained by the rate at which most browsers get updated.  After that it could be disabled by default and require the user to enable, or pop up some warning thingy to approve; and ultimately removed altogether someday.

But with SDES, we're basically asking the browsers to implement something they don't need to implement for browser-to-browser uses. (in fact, we'd define it in such a way that SDES wouldn't be used for browser-to-browser cases)  Unless some major service like Skype uses SDES, browsers vendors have no real market force keeping them supporting it.  The ones involved in this WG have already said they don't consider the WebRTC-SIP use case very important in the grand scheme of things.


> Plus there's lots of counterexamples where major sites have been compromised in ways that could have been fixed browser-side, and yet browsers didn't bother to update.

Some browsers won't update, for sure - but that's the problem with these things: it's a lowest-common-denominator model, because having media work is not an optional feature.  If you want to support all (major) browsers, you need to do what all of them can do.  You'd have to support DTLS-SRTP somehow, if even one of the major browser vendors only do DTLS-SRTP.

Sure you can save some cost by tracking how many people use what browsers, and deploying for the ratio of DTLS-SRTP vs. SDES you expect, etc.  And that will work for some operators of WebRTC sites/gateways (though not all).  But it still detracts from the arguments I and others have been making about what the benefits of having SDES would be.


> And finally, what makes you think that the browser vendors would do something like that if the service really was popular? I guess if Google and Mozilla wanted everyone using Skype to switch to Internet Explorer they could pull such a stunt, but why? (In a hypothetical future where IE has webrtc support and Skype supports webrtc-equipped browsers as a platform for calling, of course)

If there's a really popular service using SDES, like let's say Skype, I would expect the browser vendors to keep SDES support optional with a configuration thingy; or to keep it by default but only until Skype switched away from SDES.[1]  And I bet Skype would switch away quickly, if a security vulnerability made the press/slashdot.  

My point wasn't that it would literally happen in 24 hours - it was more that such a change is uncontrollable by all the operators of WebRTC sites/gateways.  Skype might be big enough to keep browsers from removing SDES, but that just moves the problem around: now all the other WebRTC sites/gateways have to change to using DTLS-SRTP when Skype changes.  Either way, they can't control their own destiny.



>> Or if the WG prefers, we could even write a separate doc on what a web-
>> based framework maker should consider supporting/not-supporting. (I can
>> imagine a few other things they might want to offer that a browser can't)
> 
> They might be able to turn ICE off, even!

Yup.  That would be #2 on the list of things an app should be able to do, right after using SDES. (or maybe the priority should even be swapped)

-hadriel
[1] having said that, there have been cases where the market power of a browser overcame the market power of a really popular service - like Apple's iOS-based Safari's lack of Flash support, with respect to YouTube service.