Re: [rtcweb] SDP Security Descriptions (RFC 4568) and RTCWeb

[Randell Jesup <[e-mail]>]

On 4/25/2013 4:27 PM, Matthew Kaufman (SKYPE) wrote:
> I agree. The ability to set the cipher suite and keys from JavaScript is critical for certain applications. SDES is the best we'll get with SDP as the API. DTLS-SRTP-only would be unacceptably limiting.

So, the problems with SDES (discussed to a fare-the-well every 3 months 
for the last 1.75 years or more, so there's nothing really new here):

It exposes security keys directly to the application (or takes them from 
there).  Basically, you're back in "all your media is totally in trust 
to the application and website".  The keys aren't even end-2-end 
encrypted or even authenticated.  And even if you expose SDES bid-downs 
to the user, they don't know what they mean or how to process this 
information.

SDES basically means to me "secure against random WiFi sniffers at the 
coffeeshop", and little more than that.  I realize carriers and others 
like SDES because they make certain uses and obligations easy for them 
to meet, and interop with legacy devices and systems easier (though many 
such legacy interop systems will perforce need gateways anyways, and 
those gateways can convert from DTLS-SRTP to SDES.

Yes, some gateway scenarios might be cheaper/easier with SDES, but I see 
the primary use-cases for WebRTC to be browser-to-browser, not 
browser-legacy.  Certainly some large organizations are built around the 
VoIP/net to legacy equipment/PSTN/PBX use-case, and certainly they would 
find SDES easier.

But I think we need to weigh that against the longer term, and the 
interests of the users (not the providers) -- the users aren't generally 
at this table; the IETF is full of people who almost by definition work 
for the companies that provide data and services. (Not everyone, but most.)

I realize there are some (many) who have 
business/organizational/political reasons to avoid end-2-end 
encryption.  However, per IETF norms (RFC 2084) we should not be letting 
that decide this issue.


It's tough to find a way to allow SDES in the "connect to a gateway that 
will decrypt anyways" case, while also avoid bid-down attacks on 
browser-browser communication.  (and EKT has some of the same key 
control issues)

We can say "we enforce DTLS-SRTP only for secure, authenticated" calls 
like ekr presented (with media tainting, etc) - but that mode isn't the 
default and really can't be/won't be for many users and applications, 
making it at best an obscure option for most people. An app (or browser 
chrome) could put a "renegotiate/re-encrypt NOW with only DTLS-SRTP" 
button up, but I doubt most apps would bother, and it might be a 
struggle to get all browsers to include such an option I suspect.  And 
even that might/would be hard to convey to users.  But maybe that's the 
best we can do.  If so, it's a sad day we can't collectively figure out 
something better.

-- 
Randell Jesup
[e-mail]