Re: [rtcweb] SRTP not mandatory-to-use

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Wed, 14 December 2011 16:38 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 9B02921F8BD5 for <rtcweb@ietfa.amsl.com>; Wed, 14 Dec 2011 08:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4WJEUR3WToXy for <rtcweb@ietfa.amsl.com>; Wed, 14 Dec 2011 08:38:48 -0800 (PST)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 02CC521F8BCB for <rtcweb@ietf.org>; Wed, 14 Dec 2011 08:38:47 -0800 (PST)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pBEGckuw012535 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Wed, 14 Dec 2011 10:38:47 -0600 (CST)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBEGckid027933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Wed, 14 Dec 2011 10:38:46 -0600
Received: from [135.222.134.168] (USMUYN0L055118.mh.lucent.com [135.222.134.168]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pBEGckj3014234; Wed, 14 Dec 2011 10:38:46 -0600 (CST)
Message-ID: <4EE8D115.9060703@alcatel-lucent.com>
Date: Wed, 14 Dec 2011 11:38:45 -0500
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAErhfrwu322=HTS0JZhum9EGfb73KmYS6CU_KMESyzEWhtvg2w@mail.gmail.com> <CABcZeBOeg-O+6===5tk0haxC8nLxUQyEUFRES2FAoFEf00fKng@mail.gmail.com>
In-Reply-To: <CABcZeBOeg-O+6===5tk0haxC8nLxUQyEUFRES2FAoFEf00fKng@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
Subject: Re: [rtcweb] SRTP not mandatory-to-use
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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: Wed, 14 Dec 2011 16:38:48 -0000

+1 with Eric's comment.

I also see some problems in the original argument.

First of all, as had been pointed to this list a while ago, once there 
is an option to decline security, people will be mislead into doing just 
that.

Second, the VPN argument is flawed in a way additional to what Eric 
pointed: My client and my server may be within the VPN,  while the 
client of my interlocutor does not have to be; then the path outside of 
VPN is exposed.

Third, I don't quite understand the 3G argument.  AKA is used to set up 
keys--and not only for the link layer protection. It is re-used later, 
via GBA, to applicataion layer authentication and session keys. IPsec is 
used in IMS for signaling--not for the voice path, and in any event the 
IPsec tunnel terminates in the network; it is not end-to-end.

Igor

On 12/14/2011 5:32 AM, Eric Rescorla wrote:
> On Wed, Dec 14, 2011 at 3:18 PM, Xavier Marjou<xavier.marjou@gmail.com>  wrote:
>> Hi,
>>
>>
>> During the last IETF meeting, there seemed to be many people willing to have
>> SRTP mandatory-to-use in the browser. However, I would like again to
>> underline that in some contexts, it is rather desirable to deactivate, via
>> the WebRTC API, the use of SRTP in order not to encrypt/decrypt at multiple
>> layers.
>>
>>
>> This may be the case in the following example: a company wants to use WebRTC
>> for communications between its co-workers only; the web server and the
>> script using WebRTC API are located on the VPN. In such a case, there is no
>> need to use SRTP. The VPN already provides encryption when needed. If
>> co-workers want to remotely access the VPN, an IPsec tool can already
>> provide the encryption. Furthermore, if they want to remotely access the VPN
>> via a 3G network, there will be encryption at layer 2 using AKA, then IPsec
>> at layer 3, and again at SRTP level if mandatory-to-use.
> I don't understand why this makes SRTP undesirable. What scarce
> resource are you conserving
> here by not using SRTP? As has been noted a number of times, the cost
> of the crypto on
> the endpoints is generally not significant.
>
> Moreover, it's not obvious that even in this setting SRTP doesn't add security
> benefit. Why are you assuming that I want everyone on the same LAN
> as me to be able to listen to my calls, even if they are my co-workers?
>
> -Ekr
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb