Re: [rtcweb] Security analysis of RTCWEB

[Bernard Aboba <[e-mail]>]

This discussion illustrates some of the issues that arise in analyzing the security of SIP-based functionality re-purposed for RTCWEB.  If we assume that signaling is not implemented natively, then we cannot depend on functionality provided within signalling in our security analysis.   This implies that the security properties of ICE, DTLS/SRTP, etc. can be different in RTCWEB than they would be within SIP.   In contrast, the security properties of media-only approaches such as ZRTP are the same regardless of the signalling approach (e.g. SIP, Jingle, etc.).  

Within DTLS/SRTP as used in SIP, RFC 4474 is utilized to provide end-to-end integrity of the SDP and address the man-in-the-middle attack you refer to below.   In a scenario where an RTCWEB application needed to interoperate with a DTLS/SRTP implementation utilizing SIP, presumably RFC 4474 would be supported. 

However, if SIP is not implemented natively, then an alternative mechanism is needed.  As you point out below, the identity provider approach described in the security draft does not address all of the potential attacks that are handled by RFC 4474 (e.g. ICE mangling).  

> Sorry, yes it should be the other way around.
> 
> I agree that eavesdropping on a DTLS-SRTP call is harder and would require a greater (initial) coding effort. But the difference is not huge as some emails seem to suggest.
> 
> 1. Search for 'a=fingerprint:' in the offer/answer SDP string and replace what comes after with your own public key fingerprint (a single, statically configured public key would probably do if synching with the TURN server is hard)
> 
> 2. Force the media to go through the TURN server by deleting all ICE candidates except the relayed one (if deleting is not possible another option is to replace the candidates with bogus ones)
> 
> 3. Modify an existing TURN server implementation so that it decrypts and re-encrypts the DTLS traffic
> 
> Regards,
> 
> Oscar Ohlsson