Re: [rtcweb] A compromise for SDES

["Hutton, Andrew" <[e-mail]>]

> On: 13 July 2013 19:07 Hadriel Kaplan Wrote:
> 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.

There is a significant cost factor in scenarios where a large percentage of sessions have to be interworked and whether the market will bear this or not it is certainly a cost that it would be good to avoid. 


> 
> 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 we can or should say that SDES SHOULD be implemented by one type of framework but not another we just need to say something consistent for all. I agree with most of what is stated in the reasoning above and given that there is a strong commercial incentive for SDES support I think keeping DTLS-SRTP as the MTI and making SDES a SHOULD would be a good compromise. 


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