Re: [rtcweb] A compromise for SDES

"Hutton, Andrew" <> Tue, 16 July 2013 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DBAAC21F9E52 for <>; Tue, 16 Jul 2013 06:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MdwYObENSvwy for <>; Tue, 16 Jul 2013 06:22:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 39EFC21F9D5D for <>; Tue, 16 Jul 2013 06:22:35 -0700 (PDT)
Received: from (unknown []) by (Server) with ESMTP id 60DC21EB868E; Tue, 16 Jul 2013 15:22:30 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 15:22:30 +0200
From: "Hutton, Andrew" <>
To: Hadriel Kaplan <>, "" <>
Thread-Topic: [rtcweb] A compromise for SDES
Thread-Index: AQHOf/PaSlG3FppoJEmuQYWCyF5yOplnS25Q
Date: Tue, 16 Jul 2013 13:22:30 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] A compromise for SDES
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jul 2013 13:22:43 -0000

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