[rtcweb] RTP-IPSec vs SRTP-DTLS [was RE: Resolving RTP/SDES question in Paris]

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

Hi all,

Could you please let me know the reason why SRTP-DTLS alone MUST be supported by WebRTC web-browser and why not RTP-IPSec. In case my device support IPSec for all application, why web-browser has to mandated for double encryption. Another assumption here is that web-browser is endpoint (commercial browsers like chrome) which is not required as access entity (like Enterprise access router, SBC) shall acts as web-browser. So, web-browser point-to-point connection may be between employee browser to Enterprise access entity which is not required to be mandated as SRTP-DTLS. Hadriel mentioned large set of call centre solution wherein web-browser is just the endpoint, one way to access call centre and there is no need to change whole call centre architecture for the same WebRTC technology in case RTP-IPSec is supported by WebRTC browser running in IPSec mobile phone. I disagree with security advocates that all call centre using RTP will be broken as this security story does not sell well in the industry so far.

Also, It is impossible to have the common UI by all web-browser and IETF specification should not try to find the way to solve that issue. 

My problem is not mandatory to implement SRTP-DTLS but the issue is at mandatory to use. IMO, RTP-IPSec should be allowed with user-consent in web-browser and don't argue that all web user in the world are dumb. In case the usecase is missing for RTP-IPSec as Randell mentioned, let us discuss in IETF-83 RTCWeb meeting.

Thanks
Partha

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf
>Of Hadriel Kaplan
>Sent: Tuesday, March 20, 2012 3:54 AM
>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