Re: [rtcweb] A compromise for SDES
"Hutton, Andrew" <andrew.hutton@siemens-enterprise.com> Tue, 16 July 2013 13:22 UTC
Return-Path: <andrew.hutton@siemens-enterprise.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAAC21F9E52 for <rtcweb@ietfa.amsl.com>; Tue, 16 Jul 2013 06:22:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.561
X-Spam-Level:
X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdwYObENSvwy for <rtcweb@ietfa.amsl.com>; Tue, 16 Jul 2013 06:22:37 -0700 (PDT)
Received: from senmx11-mx.siemens-enterprise.com (senmx11-mx.siemens-enterprise.com [62.134.46.9]) by ietfa.amsl.com (Postfix) with ESMTP id 39EFC21F9D5D for <rtcweb@ietf.org>; Tue, 16 Jul 2013 06:22:35 -0700 (PDT)
Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by senmx11-mx.siemens-enterprise.com (Server) with ESMTP id 60DC21EB868E; Tue, 16 Jul 2013 15:22:30 +0200 (CEST)
Received: from MCHP04MSX.global-ad.net ([169.254.1.137]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 15:22:30 +0200
From: "Hutton, Andrew" <andrew.hutton@siemens-enterprise.com>
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] A compromise for SDES
Thread-Index: AQHOf/PaSlG3FppoJEmuQYWCyF5yOplnS25Q
Date: Tue, 16 Jul 2013 13:22:30 +0000
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF1164963D@MCHP04MSX.global-ad.net>
References: <CA+9kkMBuCTdFsUMtmuBz6BnrSJMpHywEZU+x+m8ARnGprvzDzA@mail.gmail.com> <CABkgnnXOa44ZkZj-g6r7Qdk8dwm6m81yT4U=Q23-hE1Q7Hn22w@mail.gmail.com> <F9556428-B6B8-407D-9D62-9A1CC04D4253@oracle.com> <B2DF729D-B313-4D3E-9C06-DA00AF7A14FF@oracle.com>
In-Reply-To: <B2DF729D-B313-4D3E-9C06-DA00AF7A14FF@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.29.42.225]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [rtcweb] A compromise for SDES
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jul 2013 13:22:43 -0000
> On: 13 July 2013 19:07 Hadriel Kaplan Wrote: > To: rtcweb@ietf.org > 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 > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- Re: [rtcweb] Draft agenda for IETF 87 Emil Ivov
- Re: [rtcweb] Draft agenda for IETF 87 Martin Thomson
- Re: [rtcweb] Draft agenda for IETF 87 Cullen Jennings (fluffy)
- [rtcweb] Draft agenda for IETF 87 Ted Hardie
- Re: [rtcweb] Draft agenda for IETF 87 Martin Thomson
- Re: [rtcweb] Draft agenda for IETF 87 Cullen Jennings (fluffy)
- Re: [rtcweb] Draft agenda for IETF 87 Martin Thomson
- Re: [rtcweb] Draft agenda for IETF 87 Adam Roach
- Re: [rtcweb] Draft agenda for IETF 87 Martin Thomson
- Re: [rtcweb] Draft agenda for IETF 87 Mary Barnes
- Re: [rtcweb] Draft agenda for IETF 87 Cullen Jennings (fluffy)
- Re: [rtcweb] Draft agenda for IETF 87 Stefan Håkansson LK
- Re: [rtcweb] Draft agenda for IETF 87 - FW Issues Hutton, Andrew
- Re: [rtcweb] Draft agenda for IETF 87 Iñaki Baz Castillo
- Re: [rtcweb] Draft agenda for IETF 87 Stefan Håkansson LK
- Re: [rtcweb] Draft agenda for IETF 87 Iñaki Baz Castillo
- Re: [rtcweb] Draft agenda for IETF 87 - FW Issues Cullen Jennings (fluffy)
- Re: [rtcweb] Draft agenda for IETF 87 - FW Issues Cullen Jennings (fluffy)
- Re: [rtcweb] Draft agenda for IETF 87 - FW Issues Hutton, Andrew
- Re: [rtcweb] Draft agenda for IETF 87 - FW Issues Cullen Jennings (fluffy)
- Re: [rtcweb] Draft agenda for IETF 87 - FW Issues Hutton, Andrew
- Re: [rtcweb] Draft agenda for IETF 87 Peter Thatcher
- Re: [rtcweb] Draft agenda for IETF 87 Hadriel Kaplan
- [rtcweb] A compromise for SDES Hadriel Kaplan
- Re: [rtcweb] Draft agenda for IETF 87 Stefan Håkansson LK
- Re: [rtcweb] A compromise for SDES Bernard Aboba
- Re: [rtcweb] A compromise for SDES Stefan Håkansson LK
- Re: [rtcweb] A compromise for SDES Roman Shpount
- Re: [rtcweb] A compromise for SDES Hrishikesh Kulkarni
- Re: [rtcweb] A compromise for SDES Peter Thatcher
- Re: [rtcweb] Draft agenda for IETF 87 Suhas Nandakumar
- Re: [rtcweb] A compromise for SDES Hutton, Andrew
- Re: [rtcweb] A compromise for SDES Salvatore Loreto
- Re: [rtcweb] A compromise for SDES Matthew Kaufman (SKYPE)
- Re: [rtcweb] A compromise for SDES Matt Fredrickson
- Re: [rtcweb] A compromise for SDES Hadriel Kaplan
- Re: [rtcweb] A compromise for SDES Parthasarathi R
- Re: [rtcweb] A compromise for SDES Cullen Jennings