e2e Redux

2005-02-28

We really need to move forward with a workable solution for end-to-end encryption in Jabber/XMPP ("e2e" for short). The existing technologies and proposals include:

While I was chatting earlier today with Perry Metzger, he indicated his preference for something nice and simple along the lines of JEP-0027 (a sentiment echoed by Ian Grigg). Perry thinks the biggest failing of JEP-0027 is that it's not exactly easy to find the other person's key. But it seems that we have at least three ways to discover another person's public key over XMPP (not counting things like parking keys at HTTP URIs):

  1. Put the key in the user's vCard -- RFC 2426 has a KEY field, and this is inherited by JEP-0054. Pro: it's darn simple and straightforward, since most servers already support vcard-temp storage and retrieval. Con: we're trying to move away from the vcard-temp protocol.
  2. Publish the key to a well-known service discovery node using the "disco publish" protocol defined in JEP-0030. Pro: almost as simple as vcard-temp and more sustainable long-term if (as planned) we move away from vcard-temp. Con: not every server implementation supports disco publish yet, though they really ought to.
  3. Publish the key to a publish-subscribe node as defined in JEP-0060 so that subscribers can be informed whenever the key changes. Pro: good notification of key changes. Con: publish-subscribe services are not widespread yet and neither is client support.

Seems to me that option #2 is preferable, although option #1 is a possibility for fast deployment (migrating vCard data to a new format is a separate problem, which we will tackle once we define that format; in the meantime, why not use vcard-temp?).

Now, another failing with JEP-0027 is that it enables two things only: signed presence and encrypted message bodies. You can't use it to encrypt presence, encrypt IQs, or encrypt a complete message stanza (only the body). This is sub-optimal for a complete solution. However, it seems that we could update and obsolete JEP-0027 (new JEP, new namespace) with a proposal that encrypts the entire stanza, not just the message body, and that enables signing as well as encryption. The result would be a protocol that enables signing and encryption of complete XML stanzas (à la RFC 3923) but that retains the simplicity of JEP-0027 and does not depend on inclusion of a CPIM parser. In essence this would be an incremental improvement over the current JEP-0027 protocol (which has worked well since 1999 or early 2000) and thus would be consistent with The Law of Standards.

What else could be improved in JEP-0027? The Security Considerations and Other Known Issues sections list the following concerns:

In sum, I think a new and improved version of JEP-0027 is the best path forward for end-to-end encryption in Jabber/XMPP.

Let the flames begin!


Peter Saint-Andre > Journal