Re: [rtcweb] SRTP and "marketing"

[Randell Jesup <[e-mail]>]

On 3/28/2012 5:58 PM, Hadriel Kaplan wrote:
> On Mar 28, 2012, at 11:15 AM, Richard L. Barnes wrote:
>
>> Hadriel noted that the competitors to this technology are Skype and Flash, and it's worth considering the security situation with these technologies, because they kind of bracket RTCWEB.  With Skype (assuming they've designed it properly), there is actually a universal authentication, under a single authority.  So you really do know that you're talking to whatever Skype ID you intend to, and nobody else. With Flash, well, does anyone expect it to be secure anyway?
> As far as I know, you don't actually "know" that with Skype.  You assume it, because you trust Skype.  They could forge whatever identity they wanted to, and they can insert a recording middlebox if they wanted to, afaict.

And they do.  Very, very quietly I assume.  (I.e. they're certainly 
subject to CALEA in the US for on-net calls, and I assume have a deal 
with the FCC/etc to cover it.)  There have been a few public hints about 
this and similar deals with other countries.

>    No one is concerned about that.

Define "no one" :-)

> They also have skype-in/skype-out to/from the PSTN, and clearly in those cases they can assert whatever identity they want, and record it all.  Again no one is concerned.  Have you ever wondered why no one freaks out?

People don't freak out because a) few realize it, b) most who do realize 
it's government mandated on them, and fighting it would likely be a huge 
losing proposition for them ($$$$).  If I were a democracy activist in 
Iran or China other similar countries I would not assume Skype was safe 
(though in many of those countries it probably is, but probably not 
China).  Those are just my assumptions; small on-net companies and 
services can fly under the radar or avoid touching things that force 
them to comply (I did that at Worldgate; no PSTN access == no CALEA).

That doesn't mean I don't want to implement a truly secure 
communications ability.  Note that by "secure" here I mean "I can detect 
if the service MITMd me" -- without reading cert phrases and preferably 
without having to install client certs and somehow build a working PKI.

One idea we've had is a non-centralized WebRTC service built on 
distributed hash tables and a partial-mesh set of connections used to 
pass signaling on WebRTC (or other) data channels to set up calls, with 
some type of Id system to validate who you get connected to (since you 
can't really trust any of the nodes fully).  If an intermediary node can 
downgrade you to SDES and sniff the keys, there is no security.

An alternative would be to allow a hybrid: SDES at the start of a call 
and rekey over to DTLS-SRTP after the call is connected.  If something 
blocks the DTLS connection it would be treated as a 
gateway-to-legacy/PSTN call (i.e. show no security, though it's secure 
against non-in-path attackers); if the DTLS connection is allowed, we 
can use it to rekey to DTLS-SRTP and to verify identity.

This minimizes the risk of bid-down - the primary additional risk is 
that without initial SDES, to tap the signal you'd need to use a 
WebRTC-enabled B2BUA to accept the DTLS-SRTP connection and siphon it 
off.  Also, a "good" gateway in a pure DTLS-SRTP world might have a 
identity established ("[e-mail]"); with SDES it wouldn't by 
default (but it could if it wanted to by rekeying via DTLS also).  You 
also have a start-of-call risk where someone could see & hear until 
rekeying, and perhaps for a short while by blocking actual rekeying by 
dropping/corrupting DTLS packets, until the client either gives up or 
warns of no security.

I'm still strongly in favor of pure DTLS-SRTP - as Harald and others 
say, less moving parts and less things that need to be secured.  But 
this might be a useful compromise if we *need* to support SDES in some 
cases.

-- 
Randell Jesup
[e-mail]