Re: [rtcweb] SRTP not mandatory-to-use

[Randell Jesup <[e-mail]>]

On 1/4/2012 10:25 PM, Roman Shpount wrote:
>
> On Wed, Jan 4, 2012 at 8:35 PM, Bernard Aboba <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     [BA] An alternative is to force an initial offer preferring
>     RTP/SAVP(F).
>     That way, if both endpoints support SRTP and the offered key management
>     scheme, it is guaranteed to be negotiated.  Only if the preferred
>     option is
>     not mutually supported could an alternative be selected.
>
>
> I would actually prefer a situation where a deliberate decision by
> application developer is required to allow RTP. By default, SRTP only
> connection should be accepted with no option to bid down (ie offer with
> RTP/SAVP(F) only and no null codec). If developer specifies that
> non-secure connections are allowed, only then RTP/AVP should be present
> in the offer or accepted in the answer (with crypto attributes or some
> other way to specify that AVPS is also supported). This way there no
> "accidental" RTP connections.

As Eric R. would probably tell you, you not only have to worry about 
bid-down attacks (and they're important), but also the "threat model" 
for rtcweb is that we don't trust:
a) the JS application
b) the service provider/website
to maintain security and privacy for our conversation.  The JS 
application may be malicious or may have been subverted without 
knowledge of the provider, or the provider may have been compromised (by 
an attacker or by legal force) even if they're not actively evil.

If you mandate SRTP (and use DTLS-SRTP), then the application and the 
website never have access to the keys, and you have end-to-end security 
(modulo gateways).  If you combine that with the identity mechanisms 
from ekr's draft/presentation at Taipei, and you have verified, no MITM, 
end-to-end encryption.  (Without identity info, we have no way to detect 
a MITM attack, especially if brokered by the service provider.)
Side note: SDES generally has the same problem; the JS app and service 
provider/website have access to the keys.  (With some pain we might be 
able to encrypt the SDES keys themselves, but I'm not sure that's 
practical.)

The "interop with legacy needs no SRTP or optional SRTP" argument fails 
if we have to go through a gateway to get to legacy equipment anyways. 
And though I've tried hard to find a practical way around it, the 
'consent' requirements handled by using ICE/etc end up requiring us to 
use a gateway. If you're using a gateway to talk to legacy devices 
and/or PSTN gateways, you can include SRTP in the gateway for the webrtc 
side.


-- 
Randell Jesup
[e-mail]