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

[Randell Jesup <[e-mail]>]

On 1/5/2012 2:17 AM, Ravindran, Parthasarathi wrote:
> 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.

"and user will know the implications "

Right.  ;-)

> 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.


And those sorts of things and exception-mechanisms are a real problem 
for most users, UI-wise.  Users don't generally understand the issues or 
what they're agreeing to, no matter how scary we make the warnings.    
It helps some, but often confuses as many users as it helps.  This is 
reinforced every time I play remote-IT-person over the phone with my 
stepmother.


As for SRTP costs:

The SRTP cost for the client is low enough not to be an issue 
(measurable, but within reason on any expected hardware).

The SRTP cost on a server hosting a large number of connections (and 
mostly just routing them) may be significant to a service provider -- 
for example, games where 'broadcast' announcements to large numbers of 
connected users have to be encrypted for each connection, or a 
hangout-like conference where streams are sent to a central location and 
resent to a large number of other members (especially in the 
without-mixing case).

In these cases, the server has to encode and/or decode a medium to large 
number of streams, but isn't doing heavy processing of the decoded 
media, so SRTP cost is a much larger factor.

Similar aspects apply to WebRTC gateways, at least run on commodity 
hardware - media data isn't being processed, just streams forwarded with 
decryption/encryption (and ICE, which should be in the noise).

So, an argument can be made (from a performance of the server/gateway 
point-of-view) that there's some justification for plain RTP, at least 
in a few use cases.  However, even in those there are often privacy 
issues - for example, in a Hangout-like app allowing video to be passed 
around without encryption is a privacy risk in general, and users aren't 
well set up to evaluate the risks (and even more importantly, the 
difference in risk in different situations).


So, even though there are cost optimizations to pure RTP for servers, 
they don't (to me) justify allowing plain RTP in webrtc in general.  The 
added risk to the user of snooping (which is hard to explain to the 
user) is significant; and what is the payoff?  Mostly it's slightly 
reduced gateway/server costs (since I don't think we can eliminate a 
webrtc->legacy gateway due to the consent requirement).   If we could 
eliminate that, then you'd also get a bonus of lower delay in interop 
(or much lower in some cases).  Since I don't see that happening, the 
benefits are relatively low and the risk to users (and possible UI 
confusion) is higher.



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


-- 
Randell Jesup
[e-mail]