Re: [rtcweb] Resolving RTP/SDES question in Paris

["Ravindran, Parthasarathi" <[e-mail]>]

Jim,

As a customer, you won't really know whether the identity (DTLS-SRTP) of call center/travel site is agent or SBC. SBC can perform MITM attack easily as extending SDES-SRTP to DTLS-SRTP for call center site is feasible.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Jim Barnett
>Sent: Tuesday, March 20, 2012 4:19 AM
>To: Hadriel Kaplan; Roman Shpount
>Cc: [e-mail]
>Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
>
>On the matter of the call center/travel site recording your call:  can't
>the far-end user agent always record your call, no matter what security
>you use?  So in the case of SDES, the call center can record at their
>SBC/switch/media server (their in-house MITM), which is easier for them,
>but even with DTLS/SRTP couldn't they always record it at the agent
>desktop, if they wanted to?
>
>- Jim
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Hadriel Kaplan
>Sent: Monday, March 19, 2012 6:24 PM
>To: Roman Shpount
>Cc: [e-mail]
>Subject: Re: [rtcweb] Resolving RTP/SDES question in Paris
>
>
>While I sympathize with the concern that requiring SRTP (regardless of
>how the key is learned) is a burden for those use-cases that literally
>don't care about SRTP and for which it does not matter, such as a
>weather announcement service or an IETF meeting broadcast, I really
>think you're 'throwing out the baby with the bath-water' to propose we
>either get everything or nothing.  People won't have the identity-stuff
>for some time, and it won't be painless to make it work and deployed.
>So what you're basically saying is "you only get RTP because you can't
>prove end-to-end security".  But such "proof" rarely exists even today.
>
>Today, when you do Email or IM over HTTPS or SMTPS, that email or IM
>only goes secure to the server you're doing SMTPS or HTTPS with.  You
>have no assurance whatsoever that it stays secure from that point on,
>nor that the server doesn't log the email/IM in its entirety.  But that
>doesn't mean there's no value in using HTTPS/SMTPS to reach that first
>server.  Quite the contrary, there's significant value in it.  Just like
>there's value in using HTTPS to reach a web store-front when purchasing
>using a credit-card, even though you have no idea what the security is
>between the web-store and your actual credit-card company.
>
>In the WebRTC context, for example, I would expect a quite-popular use-
>case for WebRTC to be Business websites, such as web-storefronts, or
>customer-support sites, or airline/hotel ticket/reservations/upgrades
>sites, etc.  When connecting to the web-page of those sites, I would
>expect them to be HTTPS once I got to some point of the click-flow
>process, if not from the beginning.  If I click a "talk to us for help"
>button, I would expect that to be secure as well, as much as the HTTPS
>portion was anyway.  In this context, only allowing them to use RTP is
>silly.  SDES is reasonably secure in this context, because there is no
>other domain the call is going to.  Yes, they have my SRTP key - doesn't
>matter; yes they can log my call - doesn't matter.  But at least my
>media is secure from my laptop to their server's domain - and that does
>matter, and it's all I ever got from using HTTPS.
>
>-hadriel
>
>
>On Mar 19, 2012, at 2:15 PM, Roman Shpount wrote:
>
>> I guess my question is, when are we going to tell the user that
>connection is "secure"? What I really do not want is making the
>distinction between secured and unsecured connection so muddy, that a
>normal user will never be able to understand the difference and will
>agree to anything. Because of this, I would like to see that if
>connection is over DTLS-SRTP with a remove party verified by an identity
>provider, user would be asked if they would like to communicate with
>remote party XYZ. If this is anything else, (DTLS-SRTP with no identity,
>SDES-SRTP, or even plain RTP), user should be asked either to allow
>unsecure communication with an unknown party, or, completely prohibited
>to do so.
>>
>> I do not see the difference, as far as security is concerned, between
>SDES-SRTP and plain RTP. If we allow SDES-SRTP for compatibility
>reasons, we might as well allow plain RTP. It would be compatible with
>more devices and as insecure as SDES-SRTP. There is no requirement that
>WebRTC application must use HTTPS for signaling. If the application is
>using HTTP, all the "sitting in the airport" examples are as unsecured
>with SDES-SRTP as they are with plain RTP.
>>
>> I do not think we would be able to force WebRTC application developers
>to create a secure application unless they would decide to create care
>and effort to develop it as such. Our goal should be to provide
>application developers with tools that would allow them to create secure
>applications and with mechanisms that would allow users to identify when
>their communications are actually secure. Everything else is just adding
>random requirements to the standard.
>> _____________
>> Roman Shpount
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb
>_______________________________________________
>rtcweb mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/rtcweb