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

[Xavier Marjou <[e-mail]>]

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


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