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

[Justin Uberti <[e-mail]>]

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 <
[e-mail]> 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:[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]>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>