Re: [rtcweb] Consensus call regarding media security

[Justin Uberti <[e-mail]>]

On Thu, Mar 29, 2012 at 1:56 AM, Roman Shpount <[e-mail]> wrote:

>
> On Wed, Mar 28, 2012 at 5:08 PM, Basil Mohamed Gohar <
> [e-mail]> wrote:
>
>> The scope of WebRTC is broad enough to consider that we need to think
>> about what's best going forward with regards to its implementation.
>> Security by default is one of the best practices in general, the support
>> from the browser community and others that are behind it will definitely
>> ensure that adoption is widespread enough to make it easy enough to
>> integrate into existing systems, as free software solutions will become
>> available shortly after the standard emerges.
>>
>>
> I would actually challenge the assumption that free software will emerge.
> SRTP with SDES was released 8 years ago. The only open source library that
> supported it until recently was libsrtp, which is a broken unusable peace
> of code spaghetti (GPF crashes, two different replay DBs which do the same
> thing, random number generator that stops working after generating few
> thousand keys) that supports 2/3 of the protocol (no F8 support). Majority
> of open source (and a large number of closed source) clients use this
> library, but do not see any of those issues since very few real SRTP calls
> are actually placed. DTLS-SRTP is two years old. Support for it was just
> added to GNU TLS (unusable by many due to GNU license) and to OpenSSL
> (using above mentioned libsrtp). There is little or no experience with
> DTLS-SRTP interop. All of these things are not trivial.
>
>
This is FUD. Google+ Hangouts uses libsrtp for all of its calls, and over
the billions of minutes of call time to date, we haven't seen any crash
bugs that could be blamed on libsrtp. And we track this stuff pretty
closely.



> My point is, if we require support for encryption implementation in the
> standard and if 4 or 5 browser vendors will cooperate, we will get vast
> majority of WebRTC clients security enabled. If everything surrounding
> WebRTC will not use encryption, it is not a big loss since, in most cases,
> it is not doing now anyway.
>