Bug 30419 - Support XEP-0027 (OpenPGP for encryption) for Telepathy
Summary: Support XEP-0027 (OpenPGP for encryption) for Telepathy
Status: NEW
Alias: None
Product: Telepathy
Classification: Unclassified
Component: gabble (show other bugs)
Version: unspecified
Hardware: All All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
URL:
Whiteboard:
Keywords:
: 16707 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-09-28 06:19 UTC by Stephen Paul Weber
Modified: 2016-02-21 19:11 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stephen Paul Weber 2010-09-28 06:19:10 UTC
The FAQ lists XEP-0246+TLS as the preferred way to do e2e encryption (hopefully with RFC5081).  That XEP, however, is deferred and not recommended for implementation.  XEP-0027, however, is historical and already supported by many clients (Psi, Gajim, etc).  Implementation of XEP-0246, therefore, is implementing something few (if any) others do, and which likely no one ever will (since deferred XEPs are usually replaced by something else later, and not "reactivated"), whereas implementing XEP-0027 would give telepathy-gabble users in-protocol end-to-end OpenPGP strong encryption that is immediately compatible with existing clients and practices.
Comment 1 Maciej Piechotka 2011-01-03 05:28:09 UTC
*** Bug 16707 has been marked as a duplicate of this bug. ***
Comment 2 Simon McVittie 2012-07-17 18:56:05 UTC
Realistically, I think this is WONTFIX. XEP-0027 has some pretty serious flaws, and I would rather see effort go into XTLS and/or OTR.

(In reply to comment #0)
> The FAQ lists XEP-0246+TLS as the preferred way to do e2e encryption (hopefully
> with RFC5081).  That XEP, however, is deferred and not recommended for
> implementation.

XTLS, the former XEP-0246, has morphed into an Internet-Draft, <https://tools.ietf.org/html/draft-meyer-xmpp-e2e-encryption-02>. I still think this is a better approach to strong cryptography in XMPP than XEP-0027.

The reason nobody has implemented it yet is that good security is difficult. I think if it's worth doing, it's worth doing right.

OTR ("off-the-record messaging" as implemented in a Pidgin plugin) is another option: it's not as flexible as XTLS, but is considerably better than XEP-0027.

Some thoughts about the right way to do strong cryptography in XMPP, with specific reference to XTLS and OTR: <http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html>

> implementing XEP-0027 would give telepathy-gabble users
> in-protocol end-to-end OpenPGP strong encryption

Let's see how that compares with the potentially-desirable security properties in my mail "Goals for end-to-end security" to the list.

Confidentiality: yes, confidentiality is provided for messages. (I seem to remember hearing that encrypting messages without also signing them is a bad idea for some obscure cryptographic reason, but I can't find a reliable reference for that, so I could be wrong.)

Integrity: no, the integrity of messages is not protected. In particular, each message is entirely separate, so a "man in the middle" can silently drop some of your messages and you'll never know. In addition, the integrity of individual messages is only protected if you violate the XEP by signing as well as encrypting.

Deniability: yes, unless you violate the XEP and sign the messages as well as encrypting them.

Non-repudiability: no, unless you violate the XEP and sign the messages as well as encrypting them. (XTLS and OTR don't provide this either. I think this is appropriate.)

Strong authentication: yes if you verify key ownership out-of-band, otherwise no.

Weak authentication: no, nothing in the XMPP connection indicates which key the peer should expect to use.

Weak anonymity: yes if you use gpg --throw-keyids, otherwise no.

Strong anonymity: yes if you use gpg --throw-keyids, otherwise no. (XTLS and OTR don't provide this either. I think this is reasonable - secure anonymity is hard.)

Replay-protection: no, even if you violate the XEP and sign the messages as well as encrypting them. (In any case, you probably don't want a signed IM saying something like "yes, I agree", without context, to be something that exists... )

Perfect forward secrecy: no, losing control of the decryption key makes all past conversations decryptable.

--------

Some other interesting features of XEP-0027:

* it signs your presence (not very usefully, since it's vulnerable to replay attacks, and I'm not at all convinced that signing presence broadcasts is even useful)

* it's incredibly verbose for IMs (there's a significant per-message overhead, which is proportionally larger for IMs since they tend to be short)

* it can only carry the text <body> of a message, not XML (like OTR, but unlike XTLS)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.