Re: [rtcweb] A compromise for SDES

[Bernard Aboba <[e-mail]>]

Hadriel --
I think you've brought up a critical point, which is very worth keeping in mind throughout the discussions in IETF RTCWEB.  That is that WebRTC is really two distinct innovations -- one, a profile of "RAI 2.0" functionality, defining a core set of RTP functionality developed over the last decade (e.g. end-to-end security, adaptive HD codecs, AVPF, etc.), and the other, a set of Javascript APIs for Web browsers defined by the W3C.   IMHO,  the "RAI 2.0" aspect is likely to prove more important (and long-lived) than the W3C WEBRTC API aspect.  
Since the "RAI 2.0" profile developed by the IETF RTCWEB WG is likely to live on way beyond the useful life of the W3C WEBRTC APIs, it is critical that the protocol profiles not be distorted so as to cater to API concerns that will be difficult to justify, let alone remember, a decade from now.   If the damage brought about by an SDP-based API could be restricted solely to Web browsers without reflecting itself in expected "on the wire" behavior, I would care a lot less about it.  After all, the Internet knows how to deal with bad designs -  it just "treats them as damage and routes around them".    So to the extent that IETF RTCWEB can contain the SDP API swamp we'll all be better off -- and the swamp will be that much easier to drain down the road once it becomes clear to all that nobody really wants to live in that part of town anyway.  
As you state, the vast majority of customers I talk to are interested primarily in the "RAI 2.0" aspects of WebRTC, and only secondarily, if at all, in the W3C JS APIs.  Given the displacement of feature phones by smartphones, the growth in availability of wireless data as well as the increasing availability of connectivity that can support interactive video (all areas of very rapid growth over the next few years), the focus of realtime communications app developers I talk to is not on browser, but on the development of native applications.  And unless HTML5-based approaches such as Firefox OS gain traction, that focus is likely to remain.   
Given this, the most frequent request I hear is for a usable mobile SDK that can offer protocol compatibility with WebRTC implementations on browsers.  To succeed, that mobile SDK had better not look anything like the W3C WEBRTC API, and it also better support extensibility.  In reality, all that the IETF RTCWEB profile defines is the core set of functionality -- that set of features that MUST be supported to enable interoperability.  However, there is a lot more that a developer might want to have available for their particular application.  That might include a codec (such as AMR-NB) or a security variant such as SDES/SRTP.   Since as you note many developers aren't going to be using the W3C WEBRTC APIs anyway, whether those additional functions are supported in the W3C APIs is largely irrelevant - and so are discussions about whether this or that additional feature needs to be a "SHOULD" or a "MAY".  

> 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.