As previously mentioned, I've started to investigate ways to more fully secure the Jabber/XMPP network. One of the design decisions made by the original Jabber developers was to use a client-server architecture, similar to but (hopefully) superior to email. The jabberd 1.0 server released in May 2000 included server-to-server functionality but did not verify hostname assertions in any way (basically what email does, which is why you receive email from spoofed addresses like bill@microsoft.com and president@whitehouse.gov). In the jabberd 1.2 server (October 2000), Jer and company introduced "server dialback", which is functionally equivalent to reverse DNS lookups (thus effectively preventing address spoofing at the domain level). Although it was possible to SSL-encrypt server-to-server connections, that was never done in the various server connection manager implementations released until recently. The XMPP specs we worked on in the IETF's XMPP WG (specifically, RFC 3920) defined a way to use TLS (successor to SSL) for channel encryption of server-to-server streams, so now we have an opportunity to make server interconnections more secure. It seems like a good idea not to blow that opportunity, not only because making the network more secure is the right thing to do but also because it might encourage more organizations to connect their servers to the network.
So, how to proceed? TLS likes one to use certificates in order to verify identity (or at least continuity) at some level, so immediately folks think "we need to get Jabber server hostnames into server certificates issued by widely-accepted certification authorities" or "we need to form our own CA for the Jabber network". Yet, conversations with my friends in the security mafia as well as my reading of various insightful web pages lead me to question the value or relevance of certification authorities to securing the XMPP network. Rather than jumping to the conclusion that we need certification authorities, let's first think about what problems we're trying to solve.
Certainly we want to encrypt server-to-server communications via TLS. (Whether this leads more servers to join the network is a secondary question, the answer to which is far from clear.) It is possible to do this today using self-signed certificates. This happens to be the way I connect to a large number of servers via ssh (the fancy name for it is opportunistic cryptography). As long as the key doesn't change, I tend to be happy. If I connect from a new machine, I check the key fingerprint against what I've seen before from that domain (yes, I keep track of the fingerprints). If I didn't keep track of the fingerprints, I might ask someone I know and trust whether that fingerprint is right. One potential problem is bootstrapping: how do I know that the fingerprint is OK the very first time I connect to that machine? Well, the odds of a man in the middle attack occurring at that moment are vanishingly small, so I pretty much take a leap into the unknown. (Yes, Mallory Is Totally Mean, but we also know that Mallory Is Truly Miniscule.) If in doubt, I could talk with someone else who has connected to that machine before, or someone who administers the machine. (For example, when Peter Millard set up a new mailserver machine for jabber.org, I could have asked him about the fingerprint for that machine's RSA key.)
A lot of this comes down to trust. I trust Peter and others who run the jabber.org, xmpp.org, and jabberstudio.org domains, because I know them personally. I also trust, albeit to a somewhat lesser extent, other people whom I have interacted with only electronically -- various JEP authors, administrators of certain public Jabber servers (e.g., Matthias Wimmer, though I met him in person once), contributors to various open-source projects, representatives of certain corporations, and the like. These are people with whom I have interacted over time, and their identities seem to be stable (at least, I don't think they've been fooling me all this time), so I rely on them to some extent.
Obviously, this kind of personal trust doesn't scale, so some people want to delegate measurement of some kind of trust to a "trusted third party", i.e., a certification authority. Yet it's clear that there's no special reason to trust the certification authorities, and I have my doubts that the Jabber Software Foundation would be extraordinarily better at this within the limited XMPP community than, say, Verisign, Thawte, or CAcert is on the broader Internet. The main reason is that there's no compelling reason to trust third parties. As Ian Grigg quotes ArticSoft at his PKI page, "The only people we can rely upon is us, unless we have it in writing. So what we need is a system where we can switch on and off who we are willing to do business with whenever we choose."
That's true, but I don't think it quite goes far enough. What are the factors that lead you to decide that you are willing to do business (or, in our case, open server-to-server communications) with someone else? Well, that might vary depending on your community. In the community of Wall Street banks, the criteria might be fairly stringent (promises to abide by SEC regulations, etc.). In the community of large ISPs (say, on the order of Earthlink and BellSouth), the criteria might be business-level agreements to interoperate. In the community of Jabber services run by volunteers (say, jabber.org and amessage.de), the criteria might be self-signed certificates issued by server admins who are known to each other in some fashion. But in all cases, trust is not outsourced -- it is something for which each administrator takes responsibility.
Given these facts, I tend to doubt that we will see promiscuous interoperability in the IM space, even within the XMPP community. While some bemoan this reality ("it should be just as easy to send an IM to someone as it is to send an email"), the fact is that promiscuous interoperability in the email community has led to many, many problems, to the point now that email is a slum. I think it's much more likely that different communities within the broader XMPP community -- financial companies, oil and gas traders, insurance companies and healthcare providers, manufacturers and companies in their supply chains, large ISPs and mobile service providers, etc. -- will first seek interoperability within their smaller communities, perhaps never opening up server-to-server connections with the public XMPP network (or only on a selective basis). We can debate whether this is good or bad, but it seems to be the most likely scenario.
The TLS technology we have in RFC 3920 enables all of these sub-communities to implement whatever policies they need: specialized certification authorities for their industries, mutual recognition of organizational CAs, secure exchange of public keys triggered by business-level agreements, or what have you. I doubt that many of these sub-communities would care if the JSF decided to become a root CA for the XMPP network -- no matter what the "XMPP CA" does, they still won't connect to other sub-communities because there is no compelling reason for them to do so, and plenty of reasons not to. Thus I suggest that we limit the problem space to the "public XMPP network" and don't try to address the needs of other sub-communities -- let the Wall Street banks and so on work out their own policies within the framework of RFC 3920.
So, how to proceed on the public network? Here we may ask: is there a need for communicating one's trust in other domains? Let us say that akl.lt (a server in Lithuania) receives a server-to-server stream from bulmalug.net (a server in the Balearic Islands). Well, it doesn't know bulmalug.net from Adam. But akl.lt may (in some sense) trust the "opinion" of bigger, more established servers (say, jabber.org and amessage.de) regarding the trustworthiness of other servers on the network (is bulmalug.net a good citizen of the public XMPP network? does it follow the protocols? have we received complaints about its users? etc.). Would it be good for akl.lt to be able to "ping" amessage.de and jabber.org about its rating of or trust in bulmalug.net? Quite possibly. This would be a way to transitively deliver distributed trust. Now, an XMPP CA could be seen as a way of doing that, but one advantage of delivering indications of trust in real time across the public network is that it overcomes (in part) the unsolved and perhaps insoluble problem of certificate revocation (which the Online Certificate Status Protocol is supposed to address, though again in a centralized fashion since one is still depending on the certification authority to update the status of certificates). Why not use the power of decentralized networks to distribute trust across the network in close to real time? This means I don't have to trust one central authority -- I need to trust only those near and known to me within the network. That seems to map much better onto the natural pattern of trust than attempting to centralize it in some faceless bureaucrats (and believe me, as Executive Director of the JSF I don't want to turn into a faceless bureaucrat).
How would such trust indications work? Perhaps each server rates the other servers with which it communicates. Servers on my whitelist have positive scores, servers on my blacklist have negative scores, servers I don't know about have a score of zero. If you ask me whether I trust example.com, I tell you what I think of that server (let's say within a range of integers from -128 to +127). When you receive a connection request from a server that is new to you, you ask a few of your more-experienced "friends" and if they all come back positive (or average positive or whatever), you allow the connection. If none of your friends knows about this new server (perhaps you're jabber.org and people connect to you first because you're a big node on the network), then you have a tougher decision to make, but perhaps you establish a server registry that administrators register with before going online (not a root CA for the network, just a registry). Would this work better than establishing a root CA for the public XMPP network? There are many reasons to think it would. But, as always, the devil is in the details.
(And oh by the way, the title of this long entry is indeed a Yes reference -- I couldn't resist.)