[Telepathy] Goals for end-to-end security
Simon McVittie
simon.mcvittie at collabora.co.uk
Wed Jun 6 12:07:19 PDT 2012
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/
More information about the telepathy
mailing list