[Standards] XTLS revisited

Dave Cridland dave at cridland.net
Mon Dec 15 17:06:40 UTC 2008

On Mon Dec 15 15:46:16 2008, Peter Saint-Andre wrote:
> Recently I've been chatting with some folks off-list about  
> end-to-end
> encryption. I've concluded that while it is possible to set up an
> end-to-end XML stream (XEP-0246) using Jingle (XEP-0247) and then
> upgrade that stream to encrypted using STARTTLS, we don't need that
> complexity because you already have a reliable connection to the  
> other
> person: it's called XMPP (there's nothing to negotiate here and no  
> need
> for SOCKS5 Bytestreams or ICE-TCP or any of that madness, just use  
> for the transport). Therefore I suggest that we simplify e2e by  
> using
> something very close to the original XTLS proposal to set up, use,  
> and
> tear down and XTLS tunnel. I've outlined the protocol below.

Okay, so the gain here is that we lose the Jingle negotiation,  
effectively, and mandate something roughly equivalent to IBB.

The downside is that we lose the ability to go direct from client to  
client should we need to, and one reason for doing so would be for  
efficiency. (There are others, independent of encryption).

As I see it, there are two ways of approaching cryptography in XMPP:

1) We concentrate on getting an efficient, but basic, end-to-end  
encryption protocol, which is easy to write and deploy. I'm firmly  
convinced that the XEP-0247 approach is right here - it's allowing us  
to get the transport right, the authentication right, and all using  
existing crypto libraries as much as possible. I just don't see any  
real likelyhood of clients not being able to use Jingle, given  
XEP-0234 etc. In this scenario, the server isn't involved at all, and  
the scope for cryptography is narrow.

2) We concentrate on getting a full-featured cryptography suite in  
place, akin to S/MIME and ESS in email. In this scenario, the server  
may well be involved, discarding bad packets, verifying signatures,  
and we'd be aiming to support things like MUC and PubSub. This is not  
going to be possible with TLS, we need to go to things like XML-dsig,  
and involve triple-wrapping and other fun things.

I don't see which this proposal is addressing.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list