Did SIP just get shot?

Yesterday at a meeting in Berlin, the IETF (geekie Internet guys) basically said that DTLS (Datagram Transport Layer Security) is THE security protocol for WebRTC. More specificially, the IEFT said that WebRTC browsers shall not use anything other than DTLS and called out a big NO to something called SDES  (Session Description Protocol Security Descriptions).

I’m still struggling to get at the underlying “so what” between the two (there are numerous highly technical blog debates)  in the universal “I’m right and your mother dresses you funny” arguments that happen.

Even from day 1, this has been hotly discussed. Google implemented SDES in it’s version of WebRTC while Firefox stuck with DTLS. The argument before the IEFT was not whether to kill off DTLS but whether to also allow SDES as part of the standard.

The good news is the Internet community recognized if they had too many ways of accomplishing something, the permutation of conflict would be enormous (witness the joy of what history has done to SIP). So the answer was a resounding — NO.

From my read (and you’re welcome to flame me) the FOR SDES contingent was that it was consistent to what has been implemented in the SIP world (though frankly the vast majority of SIP implementations I’ve seen usually don’t have tons of security).  In addition, the mobile standards body (3GPP) has endorsed SDES (if they can ever figure out what IMS is supposed to do). The final argument is that a WebRTC communication headed to the SIP world won’t have to be decrypted at the front door of the SIP world and can in theory ride to the other end point (if it’s using SDES). The notion being  less equipment would be involved.

The FOR DTLS group struggled in their arguments – the primary one being that SDES was less secure and easier to intercept using well known hacker techniques. Yet they seemingly won.

When you have people focused on the head of a pin, the pin starts to seem like a big place. The reality in the grand scheme of things does it matter? WebRTC needs to accessible to the average programmer and more choices, mean more complexity and confusion. WebRTC is not about SIP, nor is it solely about telephone companies or simply voice communications. It’s about sparking a series of new methodologies for how we communicate and share. It’s a vehicle, not a destination or a space ship.

We learned a lot about IP communications with SIP. We realized some problems simply didn’t materialize that we thought would and others bit us that we felt had been nailed down. However, we need to move forward and I’m happy the IETF members dug in and held the line on simplicity.