[rtcweb] Security Architecture: SDES support is a MUST

["Domenico Colella" <[e-mail]>]

In RTCWEB Security Architecture (draft-ietf-rtcweb-security-arch-03) I noticed an open issue regarding SDES support: if browser implementations MUST or MAY support it. 
I got quite scared when I saw the word MAY.
I support the MUST option, because RTCWEB can be used not only for peer-to-peer communication (i.e. Alice calling Bob), but also to access services provided by the "calling service"  (i.e.customer support, customer attendant, voicemail ... or any service delivering also RT audio/video that can be accessed through a website). In the latter case, the user usually is already logged-in the "calling service" using a secure connection (X.509 certificate have already be used to verify calling service party) and the other endpoint usually is a server/phone in company DMZ/intranet: communication is end-to-end secured and each party trusts the other. At the moment SDES has a good support and it is not that difficult to be implemented, on the contrary DTLS-SRTP it is almost unknown.
Why a company should buy ( ? expensive ?) DTLS-SRTP gateways (? and compatible with their legacy devices ?) or translators in order to support RTCWeb instead of a SRTMP server/gateway (i.e. open-source free products as Red5) and use FLASH ? At the moment FLASH is supported  by a considerably larger number of devices, and uses codecs "more compliant" to legacy devices (iLBC is not that supported by phone equipments).
Furthermore, in this scenario, the customer using i.e. the bank website knows for sure he is communicating "privately" to his bank and trusts the webserver. Why then setup a DTLS session or  check identities ? If  the customer is sending passwords, credit card numbers,... using webserver connection why do not "trust" such connection to exchange RTP keys as well ?
The word MUST is really important, because it grants that "every" browser in the near future will support it and grants system integrators, software developers and companies investing in building RT services that SDES support will be mantained.
Regards,
Domenico Colella