Re: [rtcweb] SDES vs DTLS-SRTP revisited

[Eric Rescorla <[e-mail]>]

On Fri, Mar 16, 2012 at 8:04 AM, Oscar Ohlsson
<[e-mail]> wrote:
> Hi,
>
> There were a couple of things that I didn't explain properly in my SDES vs DTLS-SRTP presentation at the interim meeting. Since time will be short at the next meeting as well, I thought I would try to explain myself in an email.
>
> I noticed that the discussion quickly turned into a direct comparison of the two protocols. When this happens DTLS-SRTP definitely comes out as the winner and trying to defend SDES just seems foolish. But this is not the right focus of the discussion IMO. We should be looking at the system as a whole and determine more exactly the scenarios where SDES poses a security risk.
>
> The first major argument against SDES is that it doesn't offer forward secrecy. Obviously, if the remote endpoint does not support DTLS-SRTP you have to switch to SDES or plain RTP at some point. And from that point and onwards you will never have forward secrecy. The only difference is that the conversion point is moved slightly to the left (one step?) when SDES is supported. However, if web developers starts using SDES without reason (i.e. when the remote endpoint is a browser) then I agree that the lack of forward secrecy is a problem. Do people on this list believe this will be the case? Can it be prevented somehow?
>
> The second major argument is that SDES makes it possible for the service provider to intercept calls undetectable. I've been thinking about this for some time but still haven't understood the problem completely. Say that you're on a call and want to determine if the service provider is listening in:
>
> Case 1: Both endpoints support DTLS-SRTP (can be determined by asking the other party)
>
> If SDES is used you directly conclude that something fishy is going on and hang up. If DTLS-SRTP is used you compare fingerprints and hang up if they don't match. (I've assumed that a user can view detailed security information in the browser).
>
> Case 2: The other endpoint does not support DTLS-SRTP
>
> Regardless of whether SDES is allowed or not you will never be able to tell if the call is being intercepted. The best thing to do in this case is probably to simply hang up.
>
> Does the fingerprint mismatch in case 1 somehow serve as a stronger indication that the call is being intercepted? What action would a suspicious user take besides hanging up? I would be happy if someone could explain this to me.

Hi Oscar,

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.

We actually have a worked example of this with Diginotar, where a mechanical
system for detecting MITM attacks lead to a report to Google of such an
attack and, IIRC, Diginotar being removed from the root list.

Best,
-Ekr