Re: [rtcweb] Resolving RTP/SDES question in Paris

[Roman Shpount <[e-mail]>]

Here are the levels of security that we get right now:

1. DTLS SRTP with Identity provider with signaling over HTTP or HTTPS. As
long as identity provider is not compromised, user knows who they are
talking to and that conversation is reasonably secure.

2. DTLS SRTP or SDES SRTP with signaling over HTTPS. There are no
guarantees on who exactly the user is talking to, but as long we assume
that web server and javascript applications are not compromised,
conversation is secured to some application selected destination. Cannot
tell the user that the call is secure, but probably not going to be
something that can be picked up by a script kiddy with a network sniffer.

3. DTLS SRTP or SDES SRTP with signaling over HTTP. There are no guarantees
on where the application came from or who exactly you are talking to. The
conversation is encrypted, but it can either be listened to by simply
capturing the keys (SDES SRTP) or you can spoof DNS and take over the whole
web application and make DTLS SRTP talk to some sort of monitoring proxy.
No security and probably not much better then plain RTP.

So, my question is, are we going to disable WebRTC from HTTP initiated
sessions completely and show the appropriate UI confirmations (secure for 1
and unsecure for 2) or do we plan to do something different? If we allow
any non identity non DTLS SRTP communications with signaling over HTTP, we
might as well allow all of them. All of those communication modes will have
the same security downsides, and I would argue that RTP have probably the
most upsides.
_____________
Roman Shpount