Good heavens, no! While most VoIP phones don’t encypt their calls at all, a few of them have implemented SDP Security Descriptions (SDES) (RFC 4568) to negotiate SRTP SDP Security Descriptions (SDES) session keys to encrypt the call. Of all the methods the IETF has considered for this, SDES is arguably the least secure. Here’s how it works. Suppose Alice wants to talk to Bob, who lives in China. Alice’s phone generates a random session key to encrypt the conversation, but somehow Alice has to get this key into Bob’s hands so they can both use it. Her phone transmits this key via SIP to her VoIP service provider, namely her local phone company. SDES Eavesdropping Problem Her phone company, who now has full knowledge of this session key, transmits it to Bob’s phone company in China. Bob’s phone company, owned by the Chinese government, which now has full knowledge of the session key, transmits it to Bob’s phone. Now their phones are ready to start an encrypted voice conversation.
If Alice wants to talk with Bob about human rights issues, or how they might overcome trade barriers, they can both get in trouble because the Chinese government can easily monitor the call. To stay competitive in a global economy, it’s important that a company use end-to-end encryption to protect its business communications from foreign governments. Some of us have doubts about whether our domestic phone company will always act with our best interests in mind, let alone Federal agencies that want to know everything about everything.
If PGP Corp had implemented such an embarrassingly bad protocol, it would have been met with shocked disbelief in the crypto community. But VoIP product vendors seem to get away with it, probably because crypto is not part of the VoIP industry’s core competency. I’ve talked to VoIP vendors who just shrug and candidly admit they implemented SDES so they can simply check the “supports encryption” checkbox on their product feature checklist. Their excuse is that their customers have not demanded anything better.