Re: [rtcweb] Encryption mandate

["Olle E. Johansson" <[e-mail]>]

7 sep 2011 kl. 21:20 skrev Randell Jesup:

> Splitting the two topics....
> 
> 
> On 9/7/2011 3:07 AM, Olle E. Johansson wrote:
> 
>> To fearlessly  jump into another can of worms, I still think we should have confidentiality - SRTP - by default. We know that these applications will run on a myriad of devices on a myriad of networks and it will not work to let users have to decided whether or not they want confidentiality. If Skype did not have confidentiality by default, there would be articles every summer and xmas in the evening taboloids about how easy it is to listen in to your neighbours calls and that would have hurted Skype badly.
>> 
> 
> There is a strong argument for this.  The strongest argument for the other side is  you don't need a media gateway to talk to non-WebRTC endpoints, just a signalling gateway.  This means less delay potentially (especially if the application provider has gateways only in one geographic location) and less expense for the server provider for a pretty common usecase (gateway to PSTN).  The delay could be a significant issue.
> It was also brought up that some usecases for internal PBX/business use would not need/prefer forced encryption.  As mentioned at the meeting, encrypting to the media gateway only gets you a modicum of privacy (though it might protect you from the "neighbor's wifi capture" case).
> 
> You could make forced-encryption the default, and allow the application control over whether to allow it is turned off for specific cases, like a PSTN call, or under the server's control.  
If that's the case, we have to force a UI directive that all browsers adapt - like the green bar for EV certs - so the user is aware that confidentiality is missing. I don't really see a reason why servers would disable this. Weather or not they are media endpoints and if they use encryption on the other session leg is propably out of scope. Our history with the SIPS: uri has shown how hard it is to try to build a secure architecture with middlemen involved. 

> Signalling is secure, so it could even use a direct optional downgrade from SAVP* to AVP* (i.e. similar to the best-effort-strp draft)
How can you assert that signalling is secure? When, how?
> 
> It's a tough call - guaranteed (local) security is nice, but I worry about those relay cases like taiwan->USA media gateway->taiwan.  Not a huge deal on signaling/call-setup, but media...
I think that if we try to require secure media all the way through servers and gateways, we are setting the bar way too high for rtcweb. If we can handle the media that the browser handles in the local RTP streams and force that to a secure level, we have reached a good platform to continue to work with. 

In order to be able to proceed with confidentiality as a requirement, we have to discuss key exchange for the SRTP streams. I think there are at least two ways forward - to remove it from signalling path and go for an inband key exchange a la ZRTP or declare it out of scope for RTCweb and let the various protocols handle key exchange in different ways. Its going to be very hard for users to judge how secure an application is regardless of solution. Can you explain the difference between SIP SDES and ZRTP for your "normal" users? The security guy in me would of course recommend in-band so that the intermediary servers never see my key. The web guy says "oh yeah, but most of the calls will be between you and my conference mixer or media gateway anyway, so what's the difference?"

I also think that secure identites (a la RFC4474 for SIP) should also be out of scope for RTCweb, but something we can continue to work with when building the applications and protocols that use rtcweb as a media handler. This is still an issue in SIP, XMPP and many other protocols and something we really need for realtime communication.

/O