Re: [rtcweb] SRTP not mandatory-to-use
"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Thu, 12 January 2012 00:09 UTC
Return-Path: <pravindran@sonusnet.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 F196D11E808D for <rtcweb@ietfa.amsl.com>; Wed, 11 Jan 2012 16:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 PL8L-1hiR64G for <rtcweb@ietfa.amsl.com>; Wed, 11 Jan 2012 16:09:33 -0800 (PST)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2282421F84F0 for <rtcweb@ietf.org>; Wed, 11 Jan 2012 16:09:33 -0800 (PST)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id q0C0ACcM019337; Wed, 11 Jan 2012 19:10:12 -0500
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail05.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Jan 2012 19:09:27 -0500
Received: from INBA-HUB01.sonusnet.com ([10.70.51.86]) by sonusinmail02.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 05:40:21 +0530
Received: from INBA-MAIL02.sonusnet.com ([fe80::f8d4:7090:f632:bbbc]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0339.001; Thu, 12 Jan 2012 05:40:20 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Justin Uberti <juberti@google.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] SRTP not mandatory-to-use
Thread-Index: AQHMukWaZz1WoQs1jki8oX3pxLdnppXaxrEAgABFYgCAHbzFAIABKJ2AgABrxICAAHYVgIAALM6AgAAIdgCAAYb4AIAAC4KAgAAizACAAAUogIAAIqeAgADfaQCAAANpAIAIIz8AgACf//CAAFwZIIAAFXLw//+vH4CAAHXqEP//r34AgAB980CAABSNgIAAoZsg
Date: Thu, 12 Jan 2012 00:10:18 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C01DD05E7@inba-mail02.sonusnet.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> <CAD5OKxuE0VhSsjKggj1mLOseLeDXarujvAG44yHkuZttagJggw@mail.gmail.com> <CAKhHsXHnT2p7yncha5-BQ=-Lzk3-N+tuijM-UqwfP1mPUi173A@mail.gmail.com> <BLU152-W1140980759D89AC3C1D0CA93940@phx.gbl> <CA+9kkMBdX7YT1tPj5M3VrzAPKa6tXNGZVvvhjW9V4oOEC7g_kA@mail.gmail.com> <CAOJ7v-1_qMoHBb3K7rV=hG9EadqL=xn4KEdG0zdWnKZU9_TipQ@mail.gmail.com> <4AEFFC17-EF17-40F2-B83B-0B0CC44AD2C3@cisco.com> <CAKhHsXEes+Lf+uKdTrjXoy+3PMy2uNumNL-W-0s4_xRXW6FiZg@mail.gmail.com> <4F0CAC8C.8010203@wonderhamster.org> <1D062974A4845E4D8A343C6538049202074ABD3A@XMB-BGL-414.cisco.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF907@inba-mail02.sonusnet.com> <CALiegfkejnU2rTe-FibUVxTrRS9SivkhGXB5eK+FhD8Vu6iTMA@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCF9FC@inba-mail02.sonusnet.com> <CALiegfn07bS58B+4ZyzRTnO4LCpw1e96dnqpSM+TT1y3QG2Zwg@mail.gmail.com> <387F9047F55E8C42850AD6B3A7A03C6C01DCFBC1@inba-mail02.sonusnet.com> <CAOJ7v-20+yL7r+_ODx_czHTiujXZZWESaZRB7MQjhvScg3RFtw@mail.gmail.com>
In-Reply-To: <CAOJ7v-20+yL7r+_ODx_czHTiujXZZWESaZRB7MQjhvScg3RFtw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [121.242.142.186]
Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C01DD05E7inbamail02sonus_"
MIME-Version: 1.0
X-OriginalArrivalTime: 12 Jan 2012 00:10:21.0006 (UTC) FILETIME=[92ACBEE0:01CCD0BE]
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: Thu, 12 Jan 2012 00:09:35 -0000
Justin & all, As per my offline discussion in IETF-82, lot of folks has trouble in following rtcweb alias because of the massive e-mail per day. I wish the consensus of “SRTP is mandatory to use or mandatory to implement” has to be postponed at least for interim RTCWeb face-to-face meeting on 1st Feb. I see lot of e-mail chain about key management in the alias. I’ll reply in one of them for key management. Thanks Partha From: Justin Uberti [mailto:juberti@google.com] Sent: Thursday, January 12, 2012 1:22 AM To: Ravindran, Parthasarathi Cc: Iñaki Baz Castillo; rtcweb@ietf.org Subject: Re: [rtcweb] SRTP not mandatory-to-use To reply to the OP: The consensus that I see having emerged from this discussion is that SRTP should be mandatory to use, with a provision for NULL ciphers for debugging. This provision is only exposed through developer settings, and can never be invoked from the web app; for all practical purposes, applications will have to use SRTP As for the key management mechanism, SDES and DTLS will be supported; while DTLS is preferred, there are few DTLS-SRTP implementations in existence at this time. As far as I know, this is what the major WebRTC implementations are planning to do. On Wed, Jan 11, 2012 at 8:40 AM, Ravindran, Parthasarathi <pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>> wrote: Hi Inaki, I think that we are in the same page of not using plain RTP in airport with WiFi. It is the main reason for asking SRTP as a default media protocol. Also, the public internet application like Google hangout should be based on SRTP. So, Most of the WebRTC application will based on SRTP but some of the WebRTC application prefers to RTP (intranet site) which MUST NOT be restricted by IETF standard. The double encryption avoidance is the matter of optimization in network design as double encryption in endpoint calls for double decryption in the network for some of the services. I agree that it may not be problem in some of the network because of the network resource availability or network entity is not involved (browser-browser scenario) but we can't generalize this. In case it is possible, Double encryption has to be avoided and IETF has to recommend accordingly. Please read inline for more comments. Thanks Partha >-----Original Message----- >From: Iñaki Baz Castillo [mailto:ibc@aliax.net<mailto:ibc@aliax.net>] >Sent: Wednesday, January 11, 2012 4:38 PM >To: Ravindran, Parthasarathi >Cc: Muthu Arul Mozhi Perumal (mperumal); Spencer Dawkins; Alan Johnston; >Bernard Aboba; Cullen Jennings (fluffy); rtcweb@ietf.org<mailto:rtcweb@ietf.org> >Subject: Re: [rtcweb] SRTP not mandatory-to-use > >2012/1/11 Ravindran, Parthasarathi <pravindran@sonusnet.com<mailto:pravindran@sonusnet.com>>: >> Human user who "Press the 'Accept unsecure communication' button and >> you will win a car !!!" will allow RTP plug-in to install or configure >> browser to win the car. It is as good as sending the air ticket money >> to unknown country king based on spam mail in secured (https) e-mail >> access user for getting lump sum money from King (spammer). > >Right. My question is: why to allow that? wasn't a primary aim of WebRTC >to avoid such a risk? > <partha> I guess that my point does not come out well. I'm saying that user who accept unsecure communication for a car will allow RTP plug-in to be added in the browser wherein security will be compromised anyway and not related to WebRTC. </partha> > >> Also, please note that SRTP-DTLS does not prevent WebRTC server from >> accessing the secured WebRTC media (data) but helps user to identify >> that the media is not end-to-end. My statement is based on my >> understanding of WebRTC security architecture >> >> Partha(Browser + JS) ----------WebRTCserver-----Browser+ JS (Inaki) >> | | >> ----(SRTP+DTLS)-----WebRTC Media server---(SRTP+DTLS) ----- >> >> In the above topology, webserver owns WebRTC media server as well. >> Web media server terminates & originates the media. The identity is >> the differentiating factor. For example, if I see the browser window >> with identity ibc@gmail.com<mailto:ibc@gmail.com> instead of ibc@aliax.net<mailto:ibc@aliax.net>, then I have to >> understand that browser is not end-to-end because of identity. > >Well, I expect that the typicall picture will not include the "WebRTC >Media Server" (it could however). > > >> My current argument has nothing to do with PSTN interop. AFAIK, >> SRTP-DTLS standardization in WebRTC is good for SBC :-). > >Ok, but I'm not talking about that. I'm just wondering why the human >user should be able to "trust" a website asking permission for >untrusted/insecure plain RTP. This is not about having a media server or >not. > >Example: I'm in an airport with open WiFi. If I establish a plain RTP >communication anyone in that network can inspect it. Why to allow that? <partha> Agreed. Public internet WebRTC application has to be based on SRTP </partha> > >I repeat my main argument against allowing plain RTP: > >The double encryption is not a problem at all. The application (the >browser) performs SRTP encryption (no problem here!) and the TCP/IP >stack in the computer or in the router performs network encryption. >Which is the problem??? There is no problem at all. > >-- >Iñaki Baz Castillo ><ibc@aliax.net<mailto:ibc@aliax.net>> _______________________________________________ rtcweb mailing list rtcweb@ietf.org<mailto:rtcweb@ietf.org> https://www.ietf.org/mailman/listinfo/rtcweb
- Re: [rtcweb] SRTP not mandatory-to-use Xavier Marjou
- [rtcweb] SRTP not mandatory-to-use Xavier Marjou
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Iñaki Baz Castillo
- Re: [rtcweb] SRTP not mandatory-to-use Markus.Isomaki
- Re: [rtcweb] SRTP not mandatory-to-use Xavier Marjou
- Re: [rtcweb] SRTP not mandatory-to-use Igor Faynberg
- Re: [rtcweb] SRTP not mandatory-to-use Roy, Radhika R USA CIV (US)
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Harald Alvestrand
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Markus.Isomaki
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Justin Uberti
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Ted Hardie
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Alan Johnston
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Ted Hardie
- Re: [rtcweb] SRTP not mandatory-to-use Ted Hardie
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Justin Uberti
- Re: [rtcweb] SRTP not mandatory-to-use Olle E. Johansson
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Stefan Hakansson LK
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Harald Alvestrand
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Cullen Jennings
- Re: [rtcweb] SRTP not mandatory-to-use Kevin P. Fleming
- Re: [rtcweb] SRTP not mandatory-to-use Alan Johnston
- Re: [rtcweb] SRTP not mandatory-to-use Ted Hardie
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Spencer Dawkins
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Muthu Arul Mozhi Perumal (mperumal)
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Iñaki Baz Castillo
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Iñaki Baz Castillo
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Justin Uberti
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Bernard Aboba
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Justin Uberti
- Re: [rtcweb] SRTP not mandatory-to-use Justin Uberti
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- [rtcweb] JSEP draft query [was RE: SRTP not manda… Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Cullen Jennings
- [rtcweb] state of libsrtp maintenance? (Re: SRTP … Harald Alvestrand
- Re: [rtcweb] JSEP draft query [was RE: SRTP not m… Harald Alvestrand
- Re: [rtcweb] SRTP DTLS - SIPit Olle E. Johansson
- Re: [rtcweb] JSEP draft query [was RE: SRTP not m… Ravindran, Parthasarathi
- Re: [rtcweb] SRTP not mandatory-to-use Ravindran, Parthasarathi
- Re: [rtcweb] state of libsrtp maintenance? (Re: S… Roman Shpount
- Re: [rtcweb] state of libsrtp maintenance? (Re: S… Eric Rescorla
- Re: [rtcweb] SRTP DTLS - SIPit Eric Rescorla
- Re: [rtcweb] SRTP DTLS - SIPit Hannes Tschofenig
- Re: [rtcweb] state of libsrtp maintenance? (Re: S… Roman Shpount
- Re: [rtcweb] SRTP not mandatory-to-use Oscar Ohlsson
- Re: [rtcweb] state of libsrtp maintenance? (Re: S… Randell Jesup
- Re: [rtcweb] SRTP not mandatory-to-use Ted Hardie
- Re: [rtcweb] SRTP not mandatory-to-use Eric Rescorla
- Re: [rtcweb] SRTP not mandatory-to-use Harald Alvestrand
- Re: [rtcweb] SRTP not mandatory-to-use Oscar Ohlsson
- Re: [rtcweb] Security analysis of RTCWEB Bernard Aboba
- Re: [rtcweb] Security analysis of RTCWEB Eric Rescorla
- Re: [rtcweb] Security analysis of RTCWEB Igor Faynberg
- Re: [rtcweb] Security analysis of RTCWEB Bernard Aboba
- Re: [rtcweb] state of libsrtp maintenance? (Re: S… Cullen Jennings