This is silly and trying to tie it into the recent NSA revelations is disingenuous. SDES:
(a) will not be enabled by default; the developer would have to enable it explicitly?* ;
(b) is mainly intended for compatibility with existing SIP systems rather than new applications, and
(c) is no worse against an attack with even a slight level of detectability, where the server can do whatever kind of interception it wants by modifying the page JavaScript. (The exception is browser extensions.)
* I am not sure if this is actually true; the SDES draft's statement that users of SDES "can be informed of the necessary precautions" suggests that it is, but the problems draft suggests a downgrade attack, and both are somewhat confusing. I would try to figure it out for myself, but WebRTC is one of the most complicated standards I have ever even begun to understand. In any case, if it's possible for a webapp to end up using SDES without explicitly enabling it, that is a bug and should be fixed. There would probably be more productive ways to go about this than posting on HN about the NSA taking over WebRTC.
> This is silly and trying to tie it into the recent NSA revelations is disingenuous [...] (a) will not be enabled by default; the developer would have to enable it explicitly?* ;
The point of showing the relationship here is to point out that site/service operators ("The developer") in your example cannot be trusted to not be coerced into acting against the user's interest.
> (b) is mainly intended for compatibility with existing SIP systems
WebRTC cannot be directly compatible with existing SIP systems because the data transport channel must use ICE to negotiate permission to send. (Otherwise JS bugs on webpage could turn random browsers into traffic flooders.
> where the server can do whatever kind of interception it wants by modifying the page JavaScript
SDES always sends the cryptographic keys to the signaling service, so the traffic can be undetectably captured. DTLS-SRTP does not make them available at all— even to the JS. So you never get unconditionally undetectable capture— at worst you get is capture which is only detectable by users that bother to page-info->media->session ID and compare.
> a downgrade attack
Whenever a less secure channel exists you can be forced into using it by blocking the more secure one. In particular, the thread model pointed out by the recent revelations is that the "developer" (site operator) can be secretly acting against the user's best interest.
> NSA taking over WebRTC
Huh? I wasn't ambiguous about who was pushing it because I wanted to suggest it was some shadowy force. I don't think it particularly matters _who_ is pushing it. I believe that when technology creates backdoors available to third parties those backdoors will eventually be used. As an engineer in this space I believe we can only protect the public by building systems which, to the best of our ability, are structurally immune to being subverted.
(a) will not be enabled by default; the developer would have to enable it explicitly?* ;
(b) is mainly intended for compatibility with existing SIP systems rather than new applications, and
(c) is no worse against an attack with even a slight level of detectability, where the server can do whatever kind of interception it wants by modifying the page JavaScript. (The exception is browser extensions.)
* I am not sure if this is actually true; the SDES draft's statement that users of SDES "can be informed of the necessary precautions" suggests that it is, but the problems draft suggests a downgrade attack, and both are somewhat confusing. I would try to figure it out for myself, but WebRTC is one of the most complicated standards I have ever even begun to understand. In any case, if it's possible for a webapp to end up using SDES without explicitly enabling it, that is a bug and should be fixed. There would probably be more productive ways to go about this than posting on HN about the NSA taking over WebRTC.