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

[Randell Jesup <[e-mail]>]

On 4/26/2013 12:27 AM, Matthew Kaufman wrote:
> On 4/25/2013 4:40 PM, Randell Jesup wrote:
>> 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.
>
> This is true anyway, because even if we only allow DTLS-SRTP, we will 
> allow cases like (as an example) Google Hangouts... which will no 
> doubt be implemented by having the box in the middle be who you're 
> calling and doing the DTLS exchange with. And then yes, you're 
> trusting the application and website and its mixer with your media.

No argument: if you're calling into a mixer, all bets are off (it's 
secure only until it gets the data to the server/mixer).  And even 
person-to-person, without identity assertions it is MITM-able, though 
not completely undetectably - you can examine the IP addresses of the 
packet (and if you have identity assertions you have to check the 
identities, or have something to flag that there was a fingerprint/key 
change).

>
>>
>> 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.
>
> They can, but gateways that do the ICE connectivity check only were 
> already an annoyance that makes interop harder than we'd like. Now 
> we're going to force those gateways to also do DTLS-SRTP and EKT? Is 
> the goal here to put up as many roadblocks as possible to RTCWEB 
> developers who want to access networks outside of the 
> browser-to-browser case?

I agree it's inconvenient to have these requirements - I spent a bunch 
of brain cycles and some phone chats with Cullen trying to figure out a 
way to enable PSTN gateway calls to avoid needing to use ICE and avoid 
needing DTLS-SRTP, and failed.  With DNSSec it's almost possible.

>
>>
>> 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.
>
> Just because the charter was mistakenly written that way doesn't mean 
> it is true. Think of all the C2B use cases, where the agents in the 
> call center probably won't be on browsers... and even if they are, 
> those browsers will be behind systems that do things like supervisor 
> monitoring and barge-in, audit recording, etc.

I don't count that as legacy - or if it is, that's fine - the call can 
be confirmed secure to the company's gateway and the gateway can 
identify itself as the company.

>
>> Certainly some large organizations are built around the VoIP/net to 
>> legacy equipment/PSTN/PBX use-case, and certainly they would find 
>> SDES easier.
>
> And many upstarts in the space are leveraging the large legacy VoIP 
> and PSTN networks to give developers a reason to put their 
> RTCWEB-based services into their browser experiences, too.
>
>>
>> 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.
>>
>
> We could do much better security-wise... If we really wanted nobody to 
> use this stuff.

That's always the problem with strong security...  It has to be 
unobtrusive-but-functional in the "normal" cases to get widely used.  
Green-field encryption can be fairly easily strong because of lack of 
needing to interop.

-- 
Randell Jesup
[e-mail]