[Security] XEP-0166, XEP-0167, XTLS - crypto and other stories.
Justin Karneges
justin at affinix.com
Thu Dec 18 18:48:50 CST 2008
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
More information about the Security
mailing list