Re: [rtcweb] A compromise for SDES

["Matthew Kaufman (SKYPE)" <[e-mail]>]

Hadriel Kaplan:
>
> Howdy,
> Someone's asked me to explain the compromise I plan on presenting in
> Berlin now, so we have more time to argue over it or chew on it.  The reason
> I was going to wait is because I wanted to explain how I got to the point of
> thinking such a compromise would make sense.  So I'll try to do that in this
> email, which will make this email long.  Nothin' much I can do about that.
> 
> Obviously this is all my personal opinion, not that of my employer, and not a
> statement claiming to be objective fact, etc.

Likewise, in this reply where, though I like you, I don't like your proposal.

> 
> Background:
> I think many people would agree that SDES has some benefits compared to
> DTLS for those of us wishing to interface to the SIP world.  Some of those
> benefits are commercial/cost factors, some are more tangible like reducing
> early media clipping.  Whether you agree with such benefits or not, so long as
> WebRTC could support SDES in a sufficiently-secure manner, there'd be less
> concern over having it.  Most of the arguments against SDES have been
> directed at whether it could in fact be "sufficiently secure".  Personally I find
> most of the arguments against it being secure enough to be essentially FUD,
> and/or also apply to DTLS-SRTP.

I believe that once the entire system is considered, any system that allows EKT shares the same security properties as one that allows SDES, and one that does not allow EKT requires a decrypt/re-encrypt phase at the gateway that is costly.

> 
> On the flip-side, I think the commercial/cost factor for SDES is not a strong
> cause, because I believe the market will bear whatever the extra cost may
> be. (I wasn't sure of this 2 years ago when this all started, but I'm fairly
> confident of it now)  And I think having only DTLS-SRTP as MTI would have a
> marketing benefit for WebRTC as a technology, which I value highly.

The market might bear the extra cost, but it doesn't mean that it isn't extra cost (and extra environmental damage through the extra energy consumed).

> 
> 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.

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.

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)

> Even the smaller Enterprises take
> a long time to upgrade code on their servers, so even for them changing their
> gateways to suddenly support DTLS-SRTP would be unrealistic.  Imagine what
> it would be for larger providers, who might even have to deploy more
> servers to handle the sudden additional overhead of DTLS-SRTP.  Meanwhile
> a growing perc  entage of their users can no longer use the service.  That's
> bad mojo.

I argue that it'd never happen.

> 
> The things that a WebRTC-to-SIP service provider can control, and arguably
> the much larger use-case for this stuff to begin with, are not really true
> "browsers" anyway - they're web-based-framework device Apps, provided
> by the service provider to begin with.  I.e., the apps they build using web
> application framework things like PhoneGap/Cordova, Appcelerator
> Titanium, etc.  I mean using a real Browser is nice for ad-hoc stuff, like being
> able to click on a "talk to a rep" button on a website, or a webex/meetecho
> type thing; but for real communication "service", whether it be as a
> subscriber of a traditional carrier, or Skype, or an employee of an Enterprise,
> or a call-center attendant, or whatever - for those most people would never
> want to have to open a browser just to receive/make calls.  They'd give you
> an app to use instead.
> 
> So it's the app use-case that would benefit the most from SDES, especially for
> issues like media clipping.  And the app use-case doesn't have the security
> concerns nor concerns for unforeseen overnight updates.


And will probably support SDES.

> 
> The Compromise:
> So given that background, I was planning to propose that the security doc
> keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a
> statement that web-based application frameworks SHOULD also support
> SDES. (with text about why and how, etc.)

Disagree. That leads immediately to half (approximately) of the browser ecosystem not supporting SDES. That increases my cost for no true security benefit to anyone.

> 
> I don't think this is too controversial, because web-based frameworks are
> never beholden to following browser behavior anyway - they're used to
> build a native application, and native applications have a very different
> security/threat model in practice.  They're written for a specific purpose, and
> installed by users from known sources for that known purpose.  Technically,
> afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any
> requirements/mandates for native applications anyway - an app maker
> would just ignore something they don't think applies to them - but I think
> web-based frameworks do generally try to follow W3C models for Javascript
> APIs, and will likely read the IETF RFCs for the media-layer stuff too.  So I
> think having this SHOULD statement would be beneficial.
> 
> 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!

Matthew Kaufman