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

From: Xavier Marjou <[email-masked]>
Date: Wed, 14 Dec 2011 10:48:14 +0100

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.

Cheers,

Xavier

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 14 Dec 2011 16:02:46 +0530

On Wed, Dec 14, 2011 at 3:18 PM, Xavier Marjou <[email-masked]> 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
> 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
> 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.

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?

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 14 Dec 2011 12:43:02 +0100

2011/12/14 Xavier Marjou <[email-masked]>:
> The VPN already provides encryption when needed. If co-workers want to
> remotely access the VPN, an IPsec tool can already provide the encryption.

SRTP provides MUCH MORE than just that, it has been largely discussed
and explained in this maillist. Pease don't simplify so much.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: <[email-masked]>
Date: Wed, 14 Dec 2011 12:23:57 +0000

Hi Xavier,

In your case the VPN use might be good enough from enterprise IT perspective, but not necessarily for individual employees suspicious of their co-workers, or the IT department, for that matter :)

As far as I can tell, the trend in corporate services is towards service-specific end-to-end security and away from L3 VPN type of catch-all solutions. For instance, I'm now connected to my corporate e-mail over TLS and to my corporate VoIP over TLS and SRTP, not having my IPSec VPN on. 5 years ago I could only access those services using the VPN.

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Xavier Marjou
Sent: 14 December, 2011 11:48
To: [email-masked]
Subject: [rtcweb] SRTP not mandatory-to-use

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.

Cheers,
Xavier

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 14 Dec 2011 15:41:06 +0100

> 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

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

---

From: Xavier Marjou <[email-masked]>
Date: Wed, 14 Dec 2011 15:58:13 +0100

Hi Markus,

Your mail is a nice summary. However, I just want to point out that
some enterprises want VPN and plain RTP.

Xavier

On Wed, Dec 14, 2011 at 1:23 PM,  <[email-masked]> wrote:
> Hi Xavier,
>
>
>
> In your case the VPN use might be good enough from enterprise IT
> perspective, but not necessarily for individual employees suspicious of
> their co-workers, or the IT department, for that matter J
>
>
>
> As far as I can tell, the trend in corporate services is towards
> service-specific end-to-end security and away from L3 VPN type of catch-all
> solutions. For instance, I’m now connected to my corporate e-mail over TLS
> and to my corporate VoIP over TLS and SRTP, not having my IPSec VPN on. 5
> years ago I could only access those services using the VPN.
>
>
>
> Markus
>
>
>
>
>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 14 Dec 2011 11:38:45 -0500

+1 with Eric's comment.

I also see some problems in the original argument.

First of all, as had been pointed to this list a while ago, once there 
is an option to decline security, people will be mislead into doing just 
that.

Second, the VPN argument is flawed in a way additional to what Eric 
pointed: My client and my server may be within the VPN,  while the 
client of my interlocutor does not have to be; then the path outside of 
VPN is exposed.

Third, I don't quite understand the 3G argument.  AKA is used to set up 
keys--and not only for the link layer protection. It is re-used later, 
via GBA, to applicataion layer authentication and session keys. IPsec is 
used in IMS for signaling--not for the voice path, and in any event the 
IPsec tunnel terminates in the network; it is not end-to-end.

Igor

On 12/14/2011 5:32 AM, Eric Rescorla wrote:
> On Wed, Dec 14, 2011 at 3:18 PM, Xavier Marjou<[email-masked]>  wrote:
>> Hi,
>>
>>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Roy, Radhika R USA CIV (US)" <[email-masked]>
Date: Wed, 14 Dec 2011 21:19:51 +0000

Hi, all:

I also agree with Igor and other members.

VPN security can be at best up to the end-to-end network layer (layer 2/3) level, but codec-to-codec media stream (audio/video) level is not covered where SRTP comes into play for security.

Now the question comes whether it is worthwhile to take security risks that VPN does not take care of because there can be host of internal networking between the end-user's codec and the place where the VPN security boundary ends.

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Igor Faynberg
Sent: Wednesday, December 14, 2011 11:39 AM
To: [email-masked]
Subject: Re: [rtcweb] SRTP not mandatory-to-use

+1 with Eric's comment.

First of all, as had been pointed to this list a while ago, once there is an option to decline security, people will be mislead into doing just that.

Second, the VPN argument is flawed in a way additional to what Eric
pointed: My client and my server may be within the VPN,  while the client of my interlocutor does not have to be; then the path outside of VPN is exposed.

Third, I don't quite understand the 3G argument.  AKA is used to set up keys--and not only for the link layer protection. It is re-used later, via GBA, to applicataion layer authentication and session keys. IPsec is used in IMS for signaling--not for the voice path, and in any event the IPsec tunnel terminates in the network; it is not end-to-end.

Igor

On 12/14/2011 5:32 AM, Eric Rescorla wrote:
>> 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.
>>
>>
>> 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.
> 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.
>
> 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?
>
> -Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 15 Dec 2011 06:43:53 +0530

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

> 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