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

["Ravindran, Parthasarathi" <[e-mail]>]

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:[e-mail]]
>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); [e-mail]
>Subject: Re: [rtcweb] SRTP not mandatory-to-use
>
>2012/1/11 Ravindran, Parthasarathi <[e-mail]>:
>> 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 [e-mail] instead of [e-mail], 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
><[e-mail]>