[Standards] XTLS revisited

Peter Saint-Andre stpeter at stpeter.im
Mon Dec 15 19:38:43 UTC 2008

On Mon, Dec 15, 2008 at 05:06:40PM +0000, Dave Cridland wrote:
> 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 Dirk pointed out to me, if your client already supports link-local
communications and generic Jingle negotation, then the end-to-end
streams + STARTTLS stuff is easier because you just need to reuse
existing code. How many such clients are there?

> 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.

Simpler is better. We want encryption that is widely deployed. The
harder we make it, the less likely it'll get into the clients of our

> 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.

Implementability and deployability. Perfect security doesn't do anyone
any good if it isn't implemented and deployed.

More information about the Standards mailing list