Re: [rtcweb] A compromise for SDES

["Parthasarathi R" <[e-mail]>]

Hi Hadriel & all,

I agree with Hadriel that DTLS-SRTP as MTI has market benefit but still I'm
not seeing much difference in terms of end-user security. I was supporting
DTLS-SRTP earlier as MTI as WebRTC signaling may takes place in HTTP. In
reality, HTTPS is expected by webrtc operator as they are worried about Web
signaling Security (on-path attack). In case of HTTPS based WebRTC signaling
traffic is used, I'm not seeing any difference between DTLS-SRTP & SDES
because it is possible to intercept the traffic by web provider (signaling
server) in case the web provider is intended to do so as mentioned in Sec
5.7.1. of draft-ietf-rtcweb-security-arch-07. Dr.Evil website shall design
as follows:

     -----Web Server & IdP-----
    |            |             |
Browser------B2BMGW------Browser

Back to back media gateway (B2BMGW) has the capability to terminate and
originate DTLS-SRTP webrtc media traffic without informing browser. Please
look into http://www.webrtc2sip.org/ for how easy to design such B2BMGW. 

The identity is not mandatory in WebRTC. Webrtc session request using HTTPS
URL like https://apprtc.appspot.com/?r=80112689 works well and it has good
web application like conference link. So, there is no much difference
between DTLS-SRTP & SDES-SRTP in case of no identity scenario. Even if the
identity is mandated using Idp, Dr.Evil provider shall mandate authoritative
Idp as (@drevil.com) which helps to intercept the media in B2BMGW. I could
not understand why Dr.Evil web provider will provide the mechanism for
establishing webrtc session using third party identity provider. As of now,
I'm not very clear how webrtc security trust model with DTLS-SRTP really
benefit browser user in terms of security whereas SDES-SRTP compromise the
security.

I see the difference between SDES-SRTP & DTLS-SRTP in case HTTP origin. So
apart of Hadriel compromise plan, some of the SDES compromise plan could be 

1) forbid HTTP origin when SDES is requested by API
2) forbid HTTP origin entirely and allow SDES-SRTP as one of the security
key mechanism. Let application selects its preferred security key mechanism.

Thanks
Partha

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Hadriel Kaplan
> Sent: Saturday, July 13, 2013 11:37 PM
> To: [e-mail]
> Subject: [rtcweb] A compromise for SDES
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.  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.
> 
> 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.
> 
> 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.)
> 
> 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)
> 
> -hadriel
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb