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

[Max Jonas Werner <[e-mail]>]

Partha,

On 27.06.2013 18:56, Parthasarathi R wrote:
> 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.

whether an application makes use of the identity API is up to the
developer as far as I unterstand the specs. This is why
http://dev.w3.org/2011/webrtc/editor/webrtc.html#identity states:

"WebRTC offers and answers (and hence the channels established by
RTCPeerConnection objects) can be authenticated"

I just recently gave a talk on WebRTC security and in the part about
identity I stated that anonymity is a very useful tool to ensure user's
privacy. That's why the identity services should always be optional.

Max


>> -----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