Re: [rtcweb] SDES vs DTLS-SRTP revisited

[Hadriel Kaplan <[e-mail]>]

On Mar 16, 2012, at 6:32 PM, Eric Rescorla wrote:
> 
> Yes, I think the fingerprint mismatch in case 1 serves as a stronger indication
> that something was wrong, because there is no technical reason for the
> fingerprint not to match if both sides believe they are doing DTLS. I.e.,
> it always indicates either a software defect or a man in the middle.
> And the suspicious user of course should hang up, but they should also
> post pictures to /., which, I would think, serves
> as a pretty significant deterrent to providers tampering with people's calls!
> By contrast, with SDES, the attack scenario and the legitimate scenario
> look the same.

I don't think you can jump to the conclusion that there's either a software defect or a MitM.  Imagine if WebRTC user Alice calls Bob through provider-A, using Bob's telephone number.  Provider-A supports DTLS-SRTP on its PSTN gateway, so it handles that and generates a call into the PSTN for Bob, who happens to use Provider-B.  Bob is currently on a WebRTC client connected to Provider-B, and Provider-B happens to also support DTLS-SRTP on its PSTN gateway.  So both Alice and Bob see "DTLS-SRTP", but different fingerprints.  It's not a software defect.  You could argue it's a MitM (the PSTN gateways doing what they do), and certainly there may *be* someone recording the call in the middle for all you know - but you really don't know either way.  Alice dialed Bob, and got the best case scenario given the situation.

The good news is the media is secure from the browsers to the PSTN, which is not an insignificant accomplishment.  If we're worried about WiFi - and I am, for at least marketing/perception reasons if nothing else - then we've alleviated that concern.  

So then there's slashdot.  If Alice or Bob posts to slashdot, it's bad news.  But we can hardly blame Provider-A or Provider-B, since they had no alternative.  Ironically, if WebRTC supported SDES, then Provider-A and B could do that instead, and make it clear/explicit no end-to-end guarantee can be made for the call - while *still* avoiding the main concern, which is the WiFi problem.  In some sense *we*, the IETF/W3C, would be more honest if we allowed SDES (over HTTPS) for gateway cases, since that's actually the level of security being provided.  Mandating DTLS-SRTP provides a false sense of security, and false sense of insecurity if it fails.

-hadriel