Re: Identity mechanism at risk?

>> 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, which isn't a useful proposal. We need
> independent validation of identity

You are not talking about the service doing an active MITM in the 
signaling but about the service using javascript APIs like webaudio and 
captureStream which hook in after the media is decrypted at the client?

Neither of these APIs is mentioned in the current spec.
Those attacks are detectable in the JS downloaded by the client. If 
anyone bothers to check the source code...

> and stream isolation (that is:
> isolation of the stream contents from access by JavaScript) for this to
> be anything like trustworthy.

I suspect the stream isolation aspect of the identity mechanism is the 
most important one but I haven't read a good explanation. Can you point 
me to one? The spec is a spec and geared towards implementors.

Received on Friday, 17 March 2017 15:54:56 UTC