It's official: No SDES in the browsers.

I wanted to follow up on my earlier post regarding WebRTC security. In that post, I mentioned that RTCWEB was contemplating what role, if any, SDES would play in the overall specification.

At yesterday's RTCWEB meeting, we concluded what had been a rather protracted discussion on this topic, with a wide variety of technical heavy hitters coming into express opinions on the topic. The result, as recorded in the working group minutes, is:

Question: Do we think the spec should say MUST implement SDES,
MAY implement SDES, or MUST NOT implement SDES. (Current doc
says MUST do dtls-srtp)

Substantially more support for MUST NOT than MAY or MUST

**** Consensus: MUST NOT implement SDES in the browser.

So, what does this mean? The short version is that we just avoided a very real threat to WebRTC's security model.

I'd like to put a finer point on that. There was a lot of analysis during the conversation around the difference in difficulty of mounting an active attack versus a passive attack, the ability to detect and audit possible interception, and a variety of other topics that would each require their own article (although I think Eric Rescorla's slides from that session do a good job of summarizing the issues rather concisely). Rather than go into that level of detail, I want to share a brilliant layman's description of SDES by way of an anecdote.

One of the RTCWEB working group participants brought along a companion to Berlin for this weeks' meeting. She sat in on the RTCWEB encryption discussion. When she asked what the lively conversation was all about, the working group participant directed her to the relevant portions of the SDES RFC.

Yesterday evening, when we were talking about the day's events, she summarized her impression of SDES based on this lay reading: "It's like having the most state-of-the-art safe in the world, putting all of your gold inside, and then writing the access code on the outside."