Howdy,
Someone's asked me to explain the compromise I plan on presenting in Berlin now, so we have more time to argue over it or chew on it.  The reason I was going to wait is because I wanted to explain how I got to the point of thinking such a compromise would make sense.  So I'll try to do that in this email, which will make this email long.  Nothin' much I can do about that.

Obviously this is all my personal opinion, not that of my employer, and not a statement claiming to be objective fact, etc.

Background:
I think many people would agree that SDES has some benefits compared to DTLS for those of us wishing to interface to the SIP world.  Some of those benefits are commercial/cost factors, some are more tangible like reducing early media clipping.  Whether you agree with such benefits or not, so long as WebRTC could support SDES in a sufficiently-secure manner, there'd be less concern over having it.  Most of the arguments against SDES have been directed at whether it could in fact be "sufficiently secure".  Personally I find most of the arguments against it being secure enough to be essentially FUD, and/or also apply to DTLS-SRTP.

On the flip-side, I think the commercial/cost factor for SDES is not a strong cause, because I believe the market will bear whatever the extra cost may be. (I wasn't sure of this 2 years ago when this all started, but I'm fairly confident of it now)  And I think having only DTLS-SRTP as MTI would have a marketing benefit for WebRTC as a technology, which I value highly.

Given those personal feelings, I didn't much care either way, so long as a decision was made - although I still preferred having SDES to avoid the early media clipping problem.  So when I was going to present on this topic back in the Vancouver meeting, my last slide basically said: "If we support SDES and it turns out later we were wrong, we can always rescind it".  This was based on the notion that browsers get updated all the time, especially for security issues.

But later it occurred to me that's actually the Achilles' heel of supporting SDES in WebRTC, for those of us wanting to gateway this stuff to SIP.  Imagine if it turns out we were wrong, and some expected-or-unexpected vulnerability is exploited against some large WebRTC service provider, and makes the news/slashdot.  Browser vendors would instantly have new code removing SDES support, and browsers in devices would be updated virtually overnight - some users may take a long time to upgrade their specific browsers on their specific devices - but many of them would do so within days.  That would be untenable for a WebRTC service provider.  Even the smaller Enterprises take a long time to upgrade code on their servers, so even for them changing their gateways to suddenly support DTLS-SRTP would be unrealistic.  Imagine what it would be for larger providers, who might even have to deploy more servers to handle the sudden additional overhead of DTLS-SRTP.  Meanwhile a growing percentage of their users can no longer use the service.  That's bad mojo.

The things that a WebRTC-to-SIP service provider can control, and arguably the much larger use-case for this stuff to begin with, are not really true "browsers" anyway - they're web-based-framework device Apps, provided by the service provider to begin with.  I.e., the apps they build using web application framework things like PhoneGap/Cordova, Appcelerator Titanium, etc.  I mean using a real Browser is nice for ad-hoc stuff, like being able to click on a "talk to a rep" button on a website, or a webex/meetecho type thing; but for real communication "service", whether it be as a subscriber of a traditional carrier, or Skype, or an employee of an Enterprise, or a call-center attendant, or whatever - for those most people would never want to have to open a browser just to receive/make calls.  They'd give you an app to use instead.

So it's the app use-case that would benefit the most from SDES, especially for issues like media clipping.  And the app use-case doesn't have the security concerns nor concerns for unforeseen overnight updates.

The Compromise:
So given that background, I was planning to propose that the security doc keep DTLS-SRTP as the only MTI mechanism for browsers, BUT to add a statement that web-based application frameworks SHOULD also support SDES. (with text about why and how, etc.)

I don't think this is too controversial, because web-based frameworks are never beholden to following browser behavior anyway - they're used to build a native application, and native applications have a very different security/threat model in practice.  They're written for a specific purpose, and installed by users from known sources for that known purpose.  Technically, afaik, nothing we do in RTCWEB WG or W3C's WEBRTC group have any requirements/mandates for native applications anyway - an app maker would just ignore something they don't think applies to them - but I think web-based frameworks do generally try to follow W3C models for Javascript APIs, and will likely read the IETF RFCs for the media-layer stuff too.  So I think having this SHOULD statement would be beneficial.

Or if the WG prefers, we could even write a separate doc on what a web-based framework maker should consider supporting/not-supporting. (I can imagine a few other things they might want to offer that a browser can't)

-hadriel