[Telepathy] Goals for end-to-end security

[Simon McVittie]

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/