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

[Roman Shpount <[e-mail]>]

On Wed, Jan 4, 2012 at 11:45 PM, Randell Jesup <[e-mail]>wrote:

> 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.
>
>
I agree that there are a lot of other threat models, but none of this is
addressed with a standard SRTP. If we design a different protocol (or key
management schema) and create an appropriate UI to give access to this we
can solve these problems. But, as most of us already know with HTTPS, users
will not care/know enough to use this new UI to actually verify anything,
so we will be dealing with the same set of security problems. So, from this
point of view I am not sure these problems can (and should be solved).
Also, keep in min that while adding identity to communication we should
still allow for anonymous calls.

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.
>
>
We are actually talking here about things that do not yet exist (like
end-to-end identity in SRTP) or never saw any real deployment (like
DTLS-SRTP). At this point we might as well design a new protocol. Let's
replace ICE while we are at it, and have a protocol that does key exchange,
media consent (including bandwidth and media type consent which is not part
of anything now) in one transaction. I know it is tempting to use layered
approach, but each layer we add slows down the connection time and
compromises interop and security. At least this way a WebRTC implementer
would not need to support 10 random parts of 50 different RFCs.

I agree with your point on legacy gateways. My main concern is a barrier to
entry in implementation of anything that communicates with WebRTC. The more
things needs to be implemented, working, and tested at the same time, the
harder it is to implement. With current approach, SRTP, ICE, RTP, and codec
support need to start working together. If we have an ability to turn off
SRTP, the other components are much easier to debug. If we provide no
access to key exchange, it would be almost impossible to identify bad
payload due to bad codec or media processing failure generated by a third
party component. I have to do interop with new implementations which
support encryption on the regular basis. Most of the communications from
third parties start with "can we turn the encryption off for debugging?" or
"can we turn the encryption off during development?".
_____________
Roman Shpount