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

[Eric Rescorla <[e-mail]>]

On Wed, Dec 14, 2011 at 8:11 PM, Xavier Marjou <[e-mail]> wrote:
> On Wed, Dec 14, 2011 at 11:32 AM, Eric Rescorla <[e-mail]> wrote:
>>
>> On Wed, Dec 14, 2011 at 3:18 PM, Xavier Marjou <[e-mail]> wrote:
>> > Hi,
>> >
>> >
>> > During the last IETF meeting, there seemed to be many people willing to have
>> > SRTP mandatory-to-use in the browser. However, I would like again to
>> > underline that in some contexts, it is rather desirable to deactivate, via
>> > the WebRTC API, the use of SRTP in order not to encrypt/decrypt at multiple
>> > layers.
>> >
>> >
>> > This may be the case in the following example: a company wants to use WebRTC
>> > for communications between its co-workers only; the web server and the
>> > script using WebRTC API are located on the VPN. In such a case, there is no
>> > need to use SRTP. The VPN already provides encryption when needed. If
>> > co-workers want to remotely access the VPN, an IPsec tool can already
>> > provide the encryption. Furthermore, if they want to remotely access the VPN
>> > via a 3G network, there will be encryption at layer 2 using AKA, then IPsec
>> > at layer 3, and again at SRTP level if mandatory-to-use.
>>
>> I don't understand why this makes SRTP undesirable. What scarce
>> resource are you conserving
>> here by not using SRTP? As has been noted a number of times, the cost
>> of the crypto on
>> the endpoints is generally not significant.
>
> Is there any scientific reference comparing the performances (cpu) of
> a SRTP communication vs an RTP communication on a smartphone device,
> or on an interworking network server? The feedback I have is that SRTP
> overhead is significant, at least on interworking network servers
> handling several calls in parallel. One example is
> http://trac.pjsip.org/repos/wiki/PJMEDIA-MIPS which gives figures,
> perhaps non-optimized, but figures anyway:
>
>
> 00:59:38.531 os_core_unix.c pjlib 0.9.0-trunk for POSIX initialized
> MIPS test, with CPU=180Mhz,  198.0 MIPS
> Clock  Item                                      Time     CPU    MIPS
>  Rate                                           (usec)    (%)
>  8KHz codec encode/decode - L16/8000/1           1704    0.170    0.34
>  8KHz stream TX/RX - G.711                       6786    0.679    1.34
>  8KHz stream TX/RX - G.711 SRTP 32bit           21688    2.169    4.29
>  8KHz stream TX/RX - G.711 SRTP 32bit +auth     33501    3.350    6.63
>  8KHz stream TX/RX - G.711 SRTP 80bit           21725    2.172    4.30
>  8KHz stream TX/RX - G.711 SRTP 80bit +auth     33551    3.355    6.64

I'm not sure why you chose this particular platform. It doesn't seem to really
be representative of what we are targeting.

Regardless, on desktop class machines or modern smartphones (e.g. iPhone)
the crypto shouldn't represent a particularly large fraction of the
load. For instance,
a macbook air can do something like 128 MB/s on a single core.



>> Moreover, it's not obvious that even in this setting SRTP doesn't add security
>> benefit. Why are you assuming that I want everyone on the same LAN
>> as me to be able to listen to my calls, even if they are my co-workers?
>>
>
> Adding more security like SRTP certainly adds more confidence and
> probabilities that the call is more secure. However, as most of you
> know, there is no guarantee that nobody can listen to your calls even
> with SRTP. The web server is in the path of the webrtc media IP and
> port advertised by the browser of the users; It thus has the
> possibility to modify these parameters and direct a user's browser to
> communicate towards an SRTP-to-SRTP gateway instead of the remote
> called user. The communication between the two users is made of 2 SRTP
> links, with an unencrypted access possible at the SRTP gateway.

(1) I would encourage you to read draft-ietf-rtcweb-security-01, which considers
this and other related issues in detail.

(2) I don't really see the relevance of this point to your example, which was
about people in allegedly secure network environments. My point is that
just because you are behind a firewall doesn't mean that you want everyone
behind the firewall to have access to your communications. This seems
orthogonal to the question of whether you trust the media server.

-Ekr