There have been several attempts [1][2][3][4] to define extensions to Telepathy to provide end-to-end security for Text channels, using XTLS and/or OTR.
I'm currently doing some rather speculative thinking about securing non-text content on XMPP (1-1 stream tubes and Jingle calls) using XTLS or DTLS+SRTP, which should clearly have a similar API. (I'm not guaranteeing that this will be implemented any time soon - but I'd like it to happen eventually!) I'm mostly interested in XTLS (which is the current focus of XMPP standardization work, as I understand it) but to avoid getting bogged down in the specifics of OTR and/or XTLS, I'm trying to enumerate what the requirements are/could be, so we have a checklist for proposals. In a couple of places I've mentioned PGP-signing messages, by which I mean the same sort of style as <http://xmpp.org/extensions/xep-0027.html>. I don't think that's something we should implement (on the contrary, it has some serious flaws), it's just for comparison. Security properties =================== There are various security properties that a Channel might have. People tend to lump all of these together as "security", but they're not all required in all situations, and some of them are even mutually exclusive. Given a Channel, a UI should be able to tell which of these properties, if any, are guaranteed by that Channel. Not every implementation of "security" needs all these, but we do need to be able to talk about them. (Many of these are adapted from <https://tools.ietf.org/html/draft-saintandre-xmpp-e2e-requirements-01>) * Confidentiality: Alice can send messages that nobody except the holder of a particular secret can read. This does not guarantee that the holder of that secret is really Bob - if it's someone else, that's a man-in-the-middle attack. In current Telepathy, this is Channel.I.Securable.Encrypted. XTLS and OTR both provide confidentiality. * Integrity: Alice can detect whether messages in a conversation have been tampered with (including deleting messages or inserting whole new messages) by someone other than the holder of a secret. She can't necessarily detect when she has been prevented from communicating with Bob altogether (that's unavoidable - the simplest version is that an attacker could perform a DDoS attack on Bob). XTLS provides integrity. OTR provides integrity until the conversation is over, then gives it up in favour of deniability. One of the problems of PGP-signed messages is that each message is independent, so deleting a message can't be detected. * Deniability: if Bob reveals a message from Alice after the conversation is over, he can't prove that it actually came from someone with access to Alice's long-term key. OTR provides this (that's what the name means - "off the record"). It is mutually incompatible with non-repudiability. * Non-repudiability: if Bob reveals a message from Alice after the conversation is over, he *can* prove that it actually came from Alice (more precisely: someone with access to Alice's long-term key). For instance, PGP-signing each message would provide this. I believe XTLS also provides this (but I could be wrong). It is mutually incompatible with deniability. * Strong authentication: Alice can know that the peer she is communicating with is actually Bob. Without this property, confidentiality and integrity are considerably less useful, and non-repudiability is entirely useless. XTLS and OTR both optionally provide this (you have to either validate certificates/key continuity, or use a user-visible handshake like Secure Remote Password or OTR's Socialist Millionaires' Protocol). In Telepathy this is Chan.I.Securable.Verified. * Weak authentication: in XMPP, in principle you can pass a certificate fingerprint through the signalling channel (your server and the peer's server) and use it to check the certificates used for out-of-band data like a DTLS+SRTP call. This is not proper end-to-end security - your XMPP server, your peer's XMPP server and the network between them can each act as a man-in-the-middle - but it at least makes VoIP calls as secure as "ordinary IM", which is better than nothing... * Weak anonymity: passive attackers (watching traffic but not performing a man-in-the-middle attack) can't tell what public keys the peers are using. OTR has this property. draft-saintandre-xmpp-e2e-requirements-01 asks for it (I'm not sure whether XTLS actually has it). * Strong anonymity: active attackers can't tell what public keys the peers are using. This isn't possible if the peers are using public keys to avoid MitM attacks (you can't have your cake and also eat it). draft-saintandre-xmpp-e2e-requirements-01 asks for it for cases where the peers are authenticating using a shared secret, and I believe XTLS + SRP provides it (but I could be wrong). * Replay-protection: if Alice receives a message from a previous conversation with Bob (which was intercepted and replayed by an attacker), she can tell it isn't a new message with the same content. XTLS inherits replay protection from TLS, I'm not sure whether OTR has replay-protection. PGP-signing messages (or equivalent) doesn't. * Perfect forward secrecy: if Alice has an encrypted conversation with Bob, and then Bob's key is compromised, an attacker with a logged copy of the the encrypted conversation cannot use the compromised key to decrypt it. XTLS inherits perfect forward secrecy from TLS; I think OTR has this, too. PGP-signing messages (or something equivalent) does not provide PFS. ... any I've missed? Opportunistic encryption, with an "off" switch ============================================== Even without proper authentication, opportunistically encrypting traffic would defend users against passive (i.e. undetectable) logging. It should be possible to have it be on-by-default, and encrypt everything even if you don't know that you're actually talking to the right person - but UIs shouldn't present this as fully secure (you could be being MitM'd). Within Telepathy, I'm not sure whether encryption should be opportunistic at the connection manager level or the UI level: for key continuity, there needs to be some way to specify a keypair to use, which might need UI/policy involvement. (In TLS, in particular, there's a decision to be made: do you want to be using a CA-issued certificate, or a self-signed one?) In any case, sometimes people want to have their communication logged: end-to-end encryption breaks server-side logging (that's sort of the point, after all). So, even if opportunistic encryption defaults to "on", there must be an "off" setting, either per-conversation or global. Upgrading to fully secure ========================= In situations where you do care that a particular conversation is authenticated (or perhaps that it's deniable, or whatever), it should be possible for a UI to demand particular security properties. If the protocol doesn't allow the desired security properties (e.g. you ask for encryption and deniability, in a protocol where you can have encryption or deniability but not both), this request can fail. This would also be an appropriate point to insert a choice between OTR and XTLS, or between two key keypairs (although I'm not sure how UIs would present this choice in a user-comprehensible way). Not unexpectedly downgrading ============================ We don't want this sort of thing to happen: * Alice starts to type a secret message * Bob ends an encrypted session (effectively, turns off encryption) * Alice presses "send" * The secret message is sent unencrypted so for any given Channel, the security properties provided should either always stay the same, or only go up, never down. This may mean that a particular Channel becomes unusable after the encrypted session ends, and Alice needs to open a new Channel (close the Empathy window and open a new one) in order to send further, potentially-non-secure messages to Bob. In the case of mutually exclusive security properties (deniable vs. non-repudiable), that means you'd have to start as D=False, NR=False (the connection manager makes no particular claim about deniability or non-repudiability). From there, you can either go to D=True, NR=False (which is what OTR provides), or D=False, NR=True (which is what PGP-signed messages would provide) - you can't have it both ways! Previous attempts at e2e security ================================= [1] http://lists.freedesktop.org/archives/telepathy/2009-October/003936.html [2] http://lists.freedesktop.org/archives/telepathy/2010-January/004103.html [3] http://lists.freedesktop.org/archives/telepathy/2010-December/005159.html leading to https://gitorious.org/wolfrage-telepathy/otr/commits/e2e-otr [4] http://lists.freedesktop.org/archives/telepathy/2011-May/005505.html leading to http://www.las.ic.unicamp.br/~jprvita/telepathy-spec-otr/spec/ _______________________________________________ telepathy mailing list telepathy@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/telepathy