Re: [rtcweb] SDES vs DTLS-SRTP revisited

On 03/17/2012 04:35 AM, Hadriel Kaplan wrote:
> 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.
I don't get this scenario. If Alice calls Bob using two different 
gateways, won't she go through a credentials and fingerprint exchange 
with the gateways?
In that case, wouldn't the fingerprint belong to the gateway?
> 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.
It wouldn't be the first time someone posted a story on slashdot that 
got the facts wrong...
>    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
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>