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
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb