Trusted Federation

2008-01-17

In the beginning there was jabberd 1.0, and it was good.

But there was a little problem: it would accept connections even if the peer server asserted a fake identity such as whitehouse.gov or paypal.com. I call this "promiscuous federation". The possibilities for spam were endless, and we'd been down that road with email already. We needed something better.

So Jer invented server dialback and promptly released jabberd 1.2. Now your jabber server would not accept connections without verifying that the peer server at least had a stable and proper identity, at least according to DNS. I call this "verified federation".

Around the same time we also defined a special port for SSL-encrypted client-to-server connections (5223 instead of 5222). But we never defined such a port for server-to-server connections (e.g., 5270 instead of 5269), so the best we could do for s2s was dialback.

Then we submitted the core Jabber technologies to the IETF for formalization, including security review. As a result we added support for Transport Layer Security to XML streams, to be specific STARTTLS (which enables you to "upgrade" your c2s or s2s connection from unencrypted to encrypted). This made it possible for us to achieve "secure federation": server-to-server connections that are encrypted using digital certificates.

Traditionally, admins generated what are called self-signed certificates. In other words, they just made up the certificates out of thin air. It's like me issuing my own driver's license. It may look nice, but there's no reason to trust it.

So beyond verified federation and beyond secure federation is what I called "trusted federation": server-to-server connections that are secure (via digital certificates and TLS) but that also are trusted because the certificates used are issued by a trusted root CA (or, in the real world, any CA from a list of trusted roots).

But where would server admins obtain such certificates? In the bad old days you would need to shell out a heft chunk of cash to buy a certificate from the likes of VeriSign. Enter the XMPP ICA, powered by the StartCom Root CA and funded by the XMPP Standards Foundation. Since December 2006, the XMPP ICA has issued free certificates to Jabber/XMPP server admins, and is doing so at an accelerating pace. This enables us to imagine the day when your IM and presence service will accept connections only from peer servers that have proper digital certificates. Trusted federation will have arrived.

When will it be realistic to switch over the Jabber network to secure-only connections? I'm not sure. There are probably 100,000 servers on the network, and so far the XMPP ICA has issued less than 1,000 certificates. That's only a 1% adoption rate (but server admins can obtain certificates from other providers, so the rate might be slightly higher). But the process for obtaining a certificate is relatively straightforward and the cost is easy to handle (free). So there are no major impediments to obtaining a real digital certificate for your XMPP server.

Here's an idea: why not switch the Jabber network to trusted federation on the tenth anniversary of Jabber technologies? Because Jer released the first Jabber code on January 4, 1999, we'd aim to switch on January 4, 2009. First we'd need to educate server admins, ramp up the issuance of free certificates at xmpp.net, make sure that all the existing server implementations handle the certificates correctly, etc. But I think it's doable.

At the very least, we could switch some major XMPP services (such as jabber.org) over to secure-only connections on that date and watch the server admins who are shut out upgrade in a hurry! :)

UPDATE: See also the discussion on the JAdmin list.


Peter Saint-Andre > Journal