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

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

Randell,

I agree that SRTP has to be mandated-to-implement for the reasons which you have mentioned and also agree that SRTP fallback should not be accepted by default to avoid bid-down attack.

The only possible solution for RTP media in WebRTC is to provide the user configuration in the browser (WebRTC client) to allow the trust website to create RTP media based session. In this model, (browser) user provides the consent to pass RTP media and user will know the implications. In case untrusted website asks for RTP session through JavaScript, those request will be declined. Hope it is inline with trusted model as user is responsible for RTP session and not JavaScript or web-server. 

RTP mechanism shall be used in the trusted site & network like intranet, Enterprise application. The need of RTP session is to reduce WebRTC-GW cost in performing SRTP-RTP. 

I understand that it adds up complication in browser implementation as browser has to consider both SRTP & RTP based on the configuration. It is more like pop-up is blocked in browser by default in the browser except for personal banking website based on user configuration.

My point is that WebRTC client should be flexible for different deployment rather than considering every URL is untrusted.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Randell Jesup
>Sent: Thursday, January 05, 2012 10:16 AM
>To: [e-mail]
>Subject: Re: [rtcweb] SRTP not mandatory-to-use
>
>On 1/4/2012 10:25 PM, Roman Shpount wrote:
>>
>> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba
>> <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>     [BA] An alternative is to force an initial offer preferring
>>     RTP/SAVP(F).
>>     That way, if both endpoints support SRTP and the offered key
>management
>>     scheme, it is guaranteed to be negotiated.  Only if the preferred
>>     option is
>>     not mutually supported could an alternative be selected.
>>
>>
>> I would actually prefer a situation where a deliberate decision by
>> application developer is required to allow RTP. By default, SRTP only
>> connection should be accepted with no option to bid down (ie offer
>> with
>> RTP/SAVP(F) only and no null codec). If developer specifies that
>> non-secure connections are allowed, only then RTP/AVP should be
>> present in the offer or accepted in the answer (with crypto attributes
>> or some other way to specify that AVPS is also supported). This way
>> there no "accidental" RTP connections.
>
>As Eric R. would probably tell you, you not only have to worry about
>bid-down attacks (and they're important), but also the "threat model"
>for rtcweb is that we don't trust:
>a) the JS application
>b) the service provider/website
>to maintain security and privacy for our conversation.  The JS
>application may be malicious or may have been subverted without
>knowledge of the provider, or the provider may have been compromised (by
>an attacker or by legal force) even if they're not actively evil.
>
>If you mandate SRTP (and use DTLS-SRTP), then the application and the
>website never have access to the keys, and you have end-to-end security
>(modulo gateways).  If you combine that with the identity mechanisms
>from ekr's draft/presentation at Taipei, and you have verified, no MITM,
>end-to-end encryption.  (Without identity info, we have no way to detect
>a MITM attack, especially if brokered by the service provider.) Side
>note: SDES generally has the same problem; the JS app and service
>provider/website have access to the keys.  (With some pain we might be
>able to encrypt the SDES keys themselves, but I'm not sure that's
>practical.)
>
>The "interop with legacy needs no SRTP or optional SRTP" argument fails
>if we have to go through a gateway to get to legacy equipment anyways.
>And though I've tried hard to find a practical way around it, the
>'consent' requirements handled by using ICE/etc end up requiring us to
>use a gateway. If you're using a gateway to talk to legacy devices
>and/or PSTN gateways, you can include SRTP in the gateway for the webrtc
>side.
>
>
>--
>Randell Jesup
>[e-mail]
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb