Re: [rtcweb] Consensus call regarding media security

[Roman Shpount <[e-mail]>]

On Thu, Mar 29, 2012 at 8:14 AM, Iñaki Baz Castillo <[e-mail]> wrote:

> Roman, you still don't want to see my simple example. Could you please
> reply to the following two questions rather than avoiding them?:
>
> 1) Why is better to use plain RTP in an open WiFi network (airport)
> rather than using SDES-SRTP?
>

I did not say that use of plain RTP is better in an open WiFi. what  am
saying that if I am communicating with a large number of applications it is
no worse. For me, anything that can cause protocol not to work or to be
used for some sort of an attack goes under MUST. Anything that is nice to
have should be under SHOULD. From my point of view security is a SHOULD.


> 2) Why is plain RTP better than SDES-SRTP in any other case?
>

In case of an enterprise network, their security concerns are not about
user privacy (it is not end user equipment in a first place) but adherence
to corporate standards or ability to monitor. In such cases SRTP is a
liability, not an asset. In Flash, in HTTP, in email, encryption is
optional. If you have anything where encryption is mandatory while
communicating with an external party, it is not acceptable in a lot of
enterprise or government environments. My goal is to have WebRTC
functionality available in as many places as possible, even if it means
giving up encryption in some cases.

Developing new applications is harder. If you are building a speech
recognition engine, you often need to add media support. Adding encrypted
media support is much harder. I want people to build new things with the
minimal effort, even just to educate themselves or to try new things. This
is what makes progress possible. The more things we pile up in front of
this, the harder it would be for people to do new things.


> > No encryption often means better security.
>
> Sorry, I don't agree. Encryption is not enough, of course, but it's
> better than nothing (and again: the open WiFi network in the airport).
>
> > Bot nets use encryption to
> > communicate, it does not mean they enable user security.
>
> 1) User identity authentication/validation and confidentiality
> (encryption).
>
> 2) Just confidentiality (encryption).
>
> 3) Nothing.
>
>
> 1 is better than 2 and 2 is better than 3.
>
>
>
> > In a lot of cases
> > ability for the user to check what exactly they are communicating and to
> > whom is security. As a security conscious person I do not want encrypted
> > communication from my computer or my network unless I know exactly who
> it is
> > going to. If I do not have to I would prefer my communications to be
> > unencrypted.
>
> Sure, but you are advanced user and I hope you are not talking in
> behalf of the 500 millions of Facebook users in the world.
> So you will be able to enter into your browser about://config and set
> a null crypto key for SRTP (so you get plain RTP and can debug it or
> whatever). This is confirmed to be the expectation of two browser
> vendors.
>
> And you are missing a point completely. If I am operating a corporate
network with 50,000 computers, do I need to go into about://config for all
of them? If I am put into this situation, I would just disable WebRTC
completely and call it security. This is exactly what I am trying to avoid.


>
> >> RFC 3711 was created in 2004, 8 years ago!
> >>
> >> Which "new" application you mean if it's not capable of implementing a
> >> simple specification from 2004? how "new" is it? is it really new? or
> >> is it a "SIP voicemail server" made in 2002?
> >>
> > Well let me list them: FreeSwitch, Asterisk, linphone, etc. All of those
> use
> > libsrtp. For all of them SRTP is broken. Not a single one of them
> bothered
> > to check or only recently detected problems
> > (https://issues.asterisk.org/jira/browse/ASTERISK-16665).
>
> I expect that, once SRTP becomes widely extended (thanks to WebRTC),
> developers will really want to fix their SRTP support, including
> libsrtp. But we cannot make a *new spec less secure than it can be
> just due a to a bug in a opensource library.
>

The issue is most of the developers would just look at this as a hurdle to
interop with WebRTC, instead of the enabling the security. If security
implementation is not taken seriously, you often end up with something that
can communicate but not really secure. For instance you can use a bad
algorithm to generate encryption keys and end up with keys that are easily
predictable. Result -- encrypted but unsecured traffic. Encryption should
be something that application developers can turn on or off, but unless
they want it, forcing support for it is a fulls quest.


>
> >> Sorry but I still see *no* argument at all in favour of allowing plain
> >> RTP in WebRTC. And AFAIK there is already consensus about it: plain
> >> RTP is not allowed.
> >>
> > I do not see an argument why RTP should not be allowed. I think you are
> > arguing we should require a feature (SRTP) for the sake of requiring a
> > feature.
>
> I still don't understand why everyone in an airport should be able to
> intercept my audio/video communication with a simple RTP sniffer.
>

There are enough cases where I or other users do not care if this happens,
so I think that encryption should be a SHOULD.
_____________
Roman Shpount