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

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 04 January 2012 00:28 UTC

Return-Path: <bernard_aboba@hotmail.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 4DA5F21F85C5 for <rtcweb@ietfa.amsl.com>; Tue, 3 Jan 2012 16:28:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.055
X-Spam-Level:
X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=0.543, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 MBcwYHXr6pwA for <rtcweb@ietfa.amsl.com>; Tue, 3 Jan 2012 16:28:20 -0800 (PST)
Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id A676721F85C1 for <rtcweb@ietf.org>; Tue, 3 Jan 2012 16:28:20 -0800 (PST)
Received: from BLU152-W53 ([65.55.111.72]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Jan 2012 16:28:20 -0800
Message-ID: <BLU152-W533F1DA98B3F04C5EC142E93970@phx.gbl>
Content-Type: multipart/alternative; boundary="_c2945da9-06f4-4551-acca-4064e41dfaa2_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: ted.ietf@gmail.com
Date: Tue, 03 Jan 2012 16:28:19 -0800
Importance: Normal
In-Reply-To: <CA+9kkMBwyUMAdDyQaYZBx0NYvoe3RV+VVKxzqNCC5Ui6xNdsOA@mail.gmail.com>
References: <CAErhfrwu322=HTS0JZhum9EGfb73KmYS6CU_KMESyzEWhtvg2w@mail.gmail.com>, <CABcZeBOeg-O+6===5tk0haxC8nLxUQyEUFRES2FAoFEf00fKng@mail.gmail.com>, <CAErhfrxTKdo7Z+61x5ZcDt5ZM7C7ob5LNxMzwng_kk3Uqrp2_Q@mail.gmail.com>, <4F01A790.4060704@alvestrand.no>, <4F02A061.60905@jesup.org>, <E44893DD4E290745BB608EB23FDDB762141EF8@008-AM1MPN1-042.mgdnok.nokia.com>, <4F035DD5.3050305@jesup.org>, <CAOJ7v-1dziaA_ePCuMxjn6uhBgOH=ZVybUmLBwQi5qiuyOzDMA@mail.gmail.com>, <BLU152-W469B2EB104C104547FC42393960@phx.gbl>, <CA+9kkMBwyUMAdDyQaYZBx0NYvoe3RV+VVKxzqNCC5Ui6xNdsOA@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 04 Jan 2012 00:28:20.0250 (UTC) FILETIME=[C2A64FA0:01CCCA77]
Cc: randell-ietf@jesup.org, rtcweb@ietf.org
Subject: Re: [rtcweb] SRTP not mandatory-to-use
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: Wed, 04 Jan 2012 00:28:21 -0000


Ted Hardie said: 

> I'm a little lost.  In a gateway implemented in a back-to-back user
> agent, won't you end up with the same illusion?
> 
> The case I think you're talking about is this:
> 
> UA--1<-Connection1->B2BUA/Gateway<-Connection-2->UA-2
> 
> Do you expect that the gateway would be refuse to use SRTP on one side
> if it intended not to use it on the other? 



[BA] If the SBC needed to enable communication with a legacy endpoint, then it
might want to negotiate security compatible with that endpoint. 


Today there are PSTN gateways that support SRTP with SDES, but interop is 
frequently an issue (I've had to debug interop issues countless times), so 
I've often had to advise customers to turn SRTP off until an issue was resolved. 

Few PSTN gateways support any flavor of end-to-end security today (e.g. ZRTP, DTLS/SRTP, etc.), 
so a failover option is even more likely in that case. 

> If the requirement is SRTP always for WEBRTC, then a b2bUA would have
> to run SRTP on boths ides if both UA-1 and UA-2 were WEBRTC
> applications, but that seems to be what we want.

[BA] What you're missing is what legacy systems actually implement (see the SIPIt reports).