Re: [rtcweb] No Interim on SDES at this juncture

["Parthasarathi R" <[e-mail]>]

Dan,

I'm wondering whether any identity is mandatory all for WebRTC session. I'm
asking this query as lot of WebRTC demo works well without any identity. For
example: it is possible to pass URL like
https://apprtc.appspot.com/?r=06095338 and ask the participant to join the
session.

Thanks
Partha


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Dan Wing
> Sent: Friday, June 21, 2013 11:30 PM
> To: Hadriel Kaplan
> Cc: [e-mail]
> Subject: Re: [rtcweb] No Interim on SDES at this juncture
> 
> 
> On Jun 21, 2013, at 10:14 AM, Hadriel Kaplan
> <[e-mail]> wrote:
> 
> >
> > On Jun 21, 2013, at 12:45 PM, Dan Wing <[e-mail]> wrote:
> >
> >>> We've talked about that one before I think.  If jQuery is out to
> get you, it's game over.  It's essentially equivalent to a malicious
> web-server, except of course that the operator of the web-server isn't
> intending to be malicious (which is an important distinction).  But
> again, not only does jQuery have access to information such as who
> you're talking to and when, it can also redirect your media to a
> gateway of its choosing to terminate the DTLS-SRTP and record it, by
> fiddling with the JSON/SDP stuff.
> 
> >>
> >> For the attacker to succeed with the redirection of DTLS-SRTP to a
> server it controls, the attacker would also need to modify the SDP's
> a=fingerprint line which is as  trivial as the attacker's other SDP
> modifications.  To prevent the attacker from succeeding with such
> modification, we need cryptographic identity (to protect the
> From/To/Date/a=fingerprint and other fields), and need the browser (not
> JS) to verify the identity using an external service (e.g., local disk,
> IdP separate from the web server providing us the (compromised) JS and
> the SDP).  While it is true that today we don't have a way today to
> provide that cryptographic identity (RFC4474 does not work, draft-wing-
> rtcweb-identity-media written by me and Hadriel was met with silence)
> DTLS-SRTP creates the foundation to build cryptographic identity which
> can be verified by the browser itself.  Such cryptographic identity
> protects from this specific attack, and DTLS-SRTP protects from other
> attacks.
> >
> > I agree - when we have such a thing, using DTLS-SRTP will have much
> more meaning.  But (1) there is no such thing yet, and (2) it won't
> make DTLS-SRTP nor DTLS-EKT any stronger than SDES for the SIP-gateway
> scenarios we're talking about, since the DTLS isn't going end-to-end.
> I.e., none of the calls would successfully authenticate using such an
> out-of-band mechanism, even the good ones.
> >
> > [note though I'm not saying DTLS-SRTP is useless today - quite the
> contrary, I hummed in favor of making it MTI back when that was
> decided, and I still think it should be MTI]
> 
> Will the existence of SDES prevent WebRTC from building this more
> secure system with strong identity?  That is, when we add cryptographic
> identity will that be effective to prevent a bid-down attack from DTLS-
> SRTP to SDES?  I am thinking right now that when we add identity we can
> prevent that bid-down, so at that time SDES could become a proper
> second-class citizen.
> 
> -d
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb