Re: [rtcweb] SRTP and "marketing"

[Hadriel Kaplan <[e-mail]>]

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.  No one is concerned about that.  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?


> What I'm concerned about in the RTCWEB context is that without a universal authentication/identity infrastructure, we will end up *promising* a secure call, but not *delivering* it.  I haven't done the analysis, but it does not seem implausible to me that FireSheep-like vulnerabilities are lurking here.
> So ISTM the "marketing" argument carries with it some serious risks as well as some small possible benefit.


It was my understanding firesheep only works when the connection is HTTP, because it sniffs the packets.  That's a real issue for RTP, not for SRTP (in either SDES or DTLS cases).

Of course neither I nor anyone else can really foretell what the trade press will say - but I remember what they said about SIP back when a couple ARP-spoofing "attack" tools demonstrated how to intercept RTP and play it, since I was in marketing at the time.  At the time, the articles were only advocating people should use "SRTP" instead.  They didn't care at all what the key-exchange protocol was.

-hadriel