Re: [rtcweb] Encryption mandate

[Randell Jesup <[e-mail]>]

On 9/7/2011 3:59 PM, Olle E. Johansson wrote:
> 7 sep 2011 kl. 21:20 skrev Randell Jesup:
>
>> 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?

I'm assuming the signalling is occurring as SIP over an HTTPS connection 
to the server, or SIP-over-TLS - haven't really given it a lot of 
thought other than this connection is securable is we start with an 
HTTPS connection to the server.

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

All good issues for discussion (there's been some before) that I don't 
have time to respond to right now.

-- 
Randell Jesup
[e-mail]