Eric Rescorla wrote: > I must have lost the thread of what you're trying to accomplish here > somewhere. > The basic idea behind DTLS-SRTP (and connected identity) is that you trust > the signalling channel (SIP or the XMPP channel you're using to set up the > direct connection) to accurately convey the end-party's certificate > fingerprints so they can be conveyed. There's no real intention to > verify them independently of that because the niotion is that they are > verified by RFC 4474 signatures from the proxy responsible for the > relevant section of namespace.
If you trust your XMPP server and only want to secure the audio stream against people along the way, it is fine. The e2e streams idea depends on not trusting the server. The idea was to combine this: how to set up a secure RTP stream if you do not trust the server? > we were trying to achieve because we figured that wasn't the common case. > So, I'm not sure you need any external validation, especially if you use > key continuity in the future. At least for e2e streams I need something. For secure audio streams I may not. One idea to make audio streams secure is to start an e2e stream (secure) and negotiate a rtp stream over that connection. In that case you can trust the signaling stream. I hope this makes sense. Dirk -- "I worry about my child and the Internet all the time, even though she's too young to have logged on yet. Here's what I worry about. I worry that 10 or 15 years from now, she will come to me and say 'Daddy, where were you when they took freedom of the press away from the Internet?'" -- Mike Godwin [www.eff.org]
