On Thursday 18 December 2008 12:49:50 Dave Cridland wrote: > I'd like to encourage some kind of cross-talk here, since it looks to > me like Dirk Meyer and I are thinking that having "generic security" > in Jingle (based primarily around TLS on reliable streams) might be > useful, whereas the VOIP crowd hanging out on jingle@ are focused on > [S]RTP.
We ought to have both generic security and application-specific security. The way I see it, we want TLS, DTLS, and SRTP. Use-cases: * File transfer, Client-to-client streams (XTLS), etc. For these we want to use TLS over a reliable transport. * VoIP. For this we want SRTP over a reliable or unreliable transport. I suppose we don't have an explicit use-case yet for DTLS (originally this was planned for VoIP, but now the consensus is to use SRTP). However, maybe DTLS would be ideal for a VPN tunnel or any other application that's not RTP but does want an unreliable channel. The trick is figuring out the layers to know what goes where and when. And it's not just about security layers. There's also PsuedoTcp. We talked about this stuff at the Summit, but I don't think there was any resolution? Currently Jingle has very simplistic properties for transports and requirements for applications. There's reliable and there's unreliable. That's it. So ICE-UDP says "I'm an unreliable transport" and File Transfer says "I need a reliable transport". On paper these two are incompatible, but in our minds we dream of stuff like this: ICE-TCP <-> TLS <-> File Transfer ICE-UDP <-> PsuedoTcp <-> TLS <-> File Transfer ICE-UDP <-> PsuedoTcp <-> TLS <-> Client-to-client stream ICE-UDP <-> SRTP <-> RTP ICE-UDP <-> DTLS <-> VPN We've got the endpoints defined, but it's all fog in the middle. Is TLS a transport? Is it an application? Is it a mysterious third layer? What about PsuedoTcp? Do we need to expand Jingle from being a fixed 2-layer negotiation to N-layer? I think at the very least we can push SRTP into XEP-167 (as is already the case). I also think that PsuedoTcp could probably be its own transport (copy/paste the ICE-UDP document, change the type to "reliable", change the namespace, and stick these words at the end of it: "And now after all that run a TCP stack on top"). This would mean you can't "plug in" SRTP or PsuedoTcp wherever you want in the chain, but maybe you don't want that anyway. Then the list reduces to: ICE-TCP <-> TLS <-> File Transfer PsuedoTcp <-> TLS <-> File Transfer PsuedoTcp <-> TLS <-> Client-to-client stream ICE-UDP <-> RTP (+SRTP) ICE-UDP <-> DTLS <-> VPN Now we're getting somewhere. We just need to do something about those mysterious crypto layers in the middle. Maybe XEP-166 (Jingle itself) could simply define the optional usage of TLS and DTLS over reliable and unreliable transports, respectively? In the 2-layer Jingle model they could be considered to be part of the transport, but the Jingle spec would centralize the definition so that the transport method XEPs don't have to bother about them. Reduce again: ICE-TCP (+TLS) <-> File Transfer PsuedoTcp (+TLS) <-> File Transfer PsuedoTcp (+TLS) <-> Client-to-client stream ICE-UDP <-> RTP (+SRTP) ICE-UDP (+DTLS) <-> VPN Yay? -Justin
