Re: [rtcweb] Solutions sought for non-ICE RTC calls, not +1 (Re: Requiring ICE for RTC calls)

[Iñaki Baz Castillo <[e-mail]>]

2011/9/27 Harald Alvestrand <[e-mail]>:
> The current assumption is that browsers will get Javascript from multiple
> sources, some of which will be malicious. Malicious sources cannot be
> allowed to initiate sessions without ICE, for all the reasons given in the
> "security" I-D.
>
> Before we can even consider relaxing the ICE requirement, we need to see a
> trust model formulated for who gets to decide, for a particular piece of
> Javascript, if it's allowed to operate within a relaxed trust model.
>
> So far, I have seen no such proposals. Can you who argue for this solution
> please go away and write a draft that describes one, instead of repeating
> "+1" without any new solutions?

Hi Harald. Don't take me wrong, I understand the security requeriments
and I agree with them. But I think that it would be a bit sad that
WebRTC model cannot interoperate with most of the current SIP
deployments.

Anyhow, I also think that this is the price that people involved in
SIP must pay for our laziness implementing security specifications
*already* standarized for SIP and RTP protocols.

The fact is that SIP is mostly deployed in the following scenarios:
- In local networks with an internal SIP PBX and SIP phones.
- In SIP-PSTN SIP providers.
- In operators internal infrastructure and intercommunication with
other operators.

All these scenarios can be considered "trusted" (more or less) as the
user does never talk SIP with an external unknown user. So they are
mostly "wallen gardens".

Of course this is not the case in pure Internet in which most of the
WebRTC deployments will exist, so I agree that security is more
important than compatibility with legacy SIP networks, even more when
those legacy SIP networks have no cared about security.


Anyhow, I still think that local policy (rather than mandating
SRTP+ICE in the spec) could make sense. As I've said in some other
thread, a malicious provider could invite the user (the web visitor)
to make a call to some "number" or "destination" controlled by the
malicious provider. The destination could implement SRTP+ICE so the
communication "seems secure", but nothing prevents the malicious
provider to record the video session and upload it to Youtube. It's
more or less than expecting that HTTPS solves Phishing problem in the
web (it does not).

In the same way, web browsers could come pre-configured with an
enabled checkbox:

  [X] don't allow unsecure calls

The user could disable such checkbox. Anyhow, when a call is being
established and the WebRTC stack realizes that the peer does not
support ICE and/or SRTP, it could warn the user by showing something
like a pop-up ("This call is not secure"), also providing a button
"Don't show again for this site".

I don't know if this could be enough.

Regards.



-- 
Iñaki Baz Castillo
<[e-mail]>