[Security] XEP-0166, XEP-0167, XTLS - crypto and other stories.

[Justin Karneges]

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