Re: [rtcweb] SDES vs DTLS-SRTP revisited

> -----Original Message-----
> From: rtcweb-bounces@ietf.org 
> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Igor Faynberg
> Sent: den 16 mars 2012 18:21
> To: rtcweb@ietf.org
> Subject: Re: [rtcweb] SDES vs DTLS-SRTP revisited
> 
> Oscar,
> 
> I am afraid I missed the point here.
> 
> How can one determine that the call is being listened to?   
> How can the 
> browser know whom the RTP stream is passing through?
> 
> If you know the SRTP key and filter the flow directed at me, 
> you will be on the conversation, right?
> 
> Igor

Hi Igor,

No you can't know for sure that the call is being listened to, but the behaviour is very suscpicious. If both parties support DTLS-SRTP then why did the web application switch from default DTLS-SRTP to SDES? There are not that many reasonable answers:

- interception/recording
- transcoding
- something else?

That's why I was wondering whether DTLS-SRTP fingerprint mismatch really is a stronger indication of interception. To me it's not an obvious question.

Regards,

Oscar

> 
> On 3/16/2012 11:04 AM, Oscar Ohlsson wrote:
> > ... 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
> ...
> >
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 