Re: Identity mechanism at risk?

> On 17 Mar 2017, at 15:01, Adam Roach <adam@nostrum.com> wrote:
> 
> On 3/17/17 03:51, westhawk wrote:
>> 
>>> On 17 Mar 2017, at 02:35, Cullen Jennings <fluffy@iii.ca <mailto:fluffy@iii.ca>> wrote:
>>> 
>>> 
>>> The security of WebRTC is very weak without this, 
>> 
>> That is an overstatement of the situation in my view.
>> 
>> There are several services that address the MiTM risks by adding their own
>> identity validation mechanisms which in turn verify the DTLS fingerprint. 
>> 
>> One example is wire.com <http://wire.com/> : https://medium.com/wire-news/the-road-to-a-more-private-and-secure-calling-protocol-a8f22d23f112 <https://medium.com/wire-news/the-road-to-a-more-private-and-secure-calling-protocol-a8f22d23f112>
>> Or Matrix.org <http://matrix.org/> 
>> Or https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-02 <https://tools.ietf.org/html/draft-johnston-rtcweb-zrtp-02>
>> 
>> All of these use cryptography in Javascript to validate the identity of a webRTC caller and detect MiTM.
>> The limitation is that to work both parties need to be loading the same javascript, probably from the same site.
> 
> Yes, and the DTLS-SRTP mechanism already provides pretty good protection from arbitrary-party interception of media (since the SDP contains fingerprints already). But the issue here is undetected interception of the media by the service itself. Your solution amounts to letting the foxes guard the henhouse, 


So in the case of a banking site offering a webRTC video call service allowing customers to call their agents, the 'foxes' are the javascript served from their website over https? 
I'd say that if you can't trust the javascript on a banking site, you have bigger problems than webRTC.... 
What am I missing?

(happy to take this off list if it helps).

T.