e2e Redux

by Peter Saint-Andre

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:

• old-style message encryption using PGP/GPG keys (JEP-0027) -- this has been widely deployed since 1999/2000 but has a few weaknesses that could be addressed
• a proposal for encrypted sessions (JEP-0116) -- since retracted, so probably a non-starter
• xmpp-e2e (RFC 3923) -- produced by the IETF's XMPP Working Group, but no one has implemented it yet, in large measure because it is just not very Jabber-ish and requires inclusion of a CPIM parser (of which there are none)
• other proto-proposals floating around out there (such as secure stanzas) -- well, they're proto-proposals and have not been seriously discussed as yet

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:

• "Key exchange relies on the web of trust model used on the OpenPGP keys network." -- I am not sure that this is a failing (see SSL considered harmful), and we could build stronger webs of trust via Jabber/XMPP (e.g., by using roster entries as proxies for trust webs).
• "There is no mechanism for checking a fingerprint or ownership of a key other than checking the user IDs on a key." -- See above on trust webs (e.g., I could ping someone else in my roster and see if he has the same fingerprint on file).
• "When the recipient is not mentioned in the encrypted body, replay attacks are possible on messages." -- We can solve this by always encrypting the complete stanza, not the character data of the message body.
• "Replay of the signed status is possible." -- But we could encrypt presence as well if need be.
• "It relies on signing or encryption of XML character data; therefore, it does not support signing or encryption of stanzas, and it allows signing of the presence element and encryption of the message element only. Thus the method is not acceptable when signing or encryption of full stanzas is required." -- Already addressed by encypting complete stanzas.
• "It does not enable both signing and encryption of a stanza, only signing of the presence status and encryption of the message body." -- This would be fixed in JEP27+ by specifying the order of encrypting and signing; e.g., as per section 6.5 of RFC 3923, I think we'd say that "if a stanza is both signed and encrypted, it SHOULD be signed first, then encrypted."
• "It is limited to PGP keys and does not support X.509 certificates, Kerberos, RSA keys, etc." -- I'm not sure this is really a failing, since a smart Jabber client could generate PGP keys for users and thus hide the hard parts of generating and revoking keys.
• "It does not include feature negotiation; instead, signed presence is used as an indicator of support. Because of the lack of negotiation it is possible for encrypted elements to be stored offline and then read by a client that cannot support them." -- We could write up a lightweight session negotiation format on top of JEP-0020 (or JEP-0095) in order to negotiate the use of encryption between two entities. Or a smart Jabber client could refuse to send encrypted messages to a contact for which it doesn't have a key on file (see above on key discovery).
• "It is verbose (the example encrypted is "Hi")." -- Life is hard. You want encryption, you gotta pay the price. There's always stream compression if you're really concerned about stanza sizes. And if you hit karma limits on a public Jabber server, you can always run your own server.

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