Re: [rtcweb] Consensus call regarding media security

[Iñaki Baz Castillo <[e-mail]>]

2012/3/29 Roman Shpount <[e-mail]>:
>
> On Wed, Mar 28, 2012 at 5:11 PM, Iñaki Baz Castillo <[e-mail]> wrote:
>>
>> In all those scenarios you mention, using security (SRTP) is not *bad*, is
>> it?
>> The fact that in certain scenarios it could be not needed, it does not
>> mean that "no security" is better than "security".
>>
> I actually think that you are confusing encryption with security.

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?

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




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




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



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


Regards.


-- 
Iñaki Baz Castillo
<[e-mail]>