[Telepathy] Goals for end-to-end security

[Simon McVittie]

(Please correct me if anything in this mail is wrong. I am not a
cryptographer.)

On 06/06/12 20:07, Simon McVittie wrote:
> * Confidentiality: Alice can send messages that nobody except the holder
>   of a particular secret can read.

Much like draft-saintandre-xmpp-e2e-requirements, we could divide this into:

* confidentiality from passive attackers willing/able to log traffic
  but not send their own (Encrypted only)

* confidentiality from active attackers willing/able to perform a
  man-in-the-middle attack (Encrypted + Verified)

The former protects you from undetectable logging; the latter protects
you from man-in-the-middle attacks, which risk detection.

> * 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.

After more investigation, I believe both XTLS and OTR provide a form of
deniability.

In XTLS, integrity is provided by an HMAC. Assuming that the
cryptographic hash has its claimed properties, verifying a HMAC and
applying that HMAC to data both require access to the HMAC's key; so
anyone with the ability to verify the HMAC can also apply that same HMAC
to a fraudulent data stream.

OTR states as a major feature that "the messages you send do not have
digital signatures that are checkable by a third party". This is an
advantage of OTR over PGP-signing or PGP-signing-and-encrypting each
message (the historical practice, e.g. in XEP-0027 [1])  but it is not
clear to me that it is an advantage of OTR over XTLS.

I see two applications for deniability:

* Bob wishes to prove (cryptographically) that he had a particular
  conversation with Alice. Alice wishes to cast doubt on that
  assertion, without revealing what actually took place in the
  conversation; she must demonstrate that Bob could have forged his
  supposed evidence. (If Bob is cooperating with a third entity
  attempting to prove that the conversation really occurred, that's
  basically equivalent.)

* Eve, an eavesdropper, wishes to prove (cryptographically) that
  Alice and Bob had a particular conversation. Alice and Bob wish to
  cast doubt on that assertion, without revealing what actually took
  place in the conversation.

In either case, the best that Alice can expect to achieve is to cast
doubt on the conversation: "someone claims that I had this conversation,
I deny it, it's my word against theirs".

In the first case, Bob has the necessary shared secret to decrypt the
ciphertext and find the MAC. He also has the necessary shared secret to
verify the MAC - but that fact necessarily gives him the necessary
shared secret to construct a forged TLS stream. Alice can cast doubt on
Bob's assertion by pointing out that he has all the necessary
information to fake it.

In the second case, Eve does not know what the conversation meant, and
is unable to verify the MAC anyway (she does not have the shared secret,
and in any case the MAC is inside the encryption layer).

OTR goes further than XTLS in one respect, which seems to be intended to
address the second case: Alice may deliberately publish her MAC key (in
cleartext) after it has gone out of use, which in principle enhances
deniability by allowing Eve to forge arbitrary messages purporting to be
from Alice. When presented with any transcript with the valid MAC (real
or faked), Alice can cast doubt on the assertion that the transcript is
genuine by pointing out that Eve, or anyone else on the network
transmission path, could have faked it.

It isn't clear to me when, or whether, this extra feature in OTR
actually helps: how would Eve produce a real transcript with a valid
MAC, other than by breaking the security of either Alice's or Bob's
software to obtain the decrypted transcript? If that has happened, can't
Alice and Bob cast doubt on this by pointing out that if Eve has done
so, she could equally well have obtained the MAC and used it to forge
the transcript? If the validity of the MAC is being shown to a third
party (e.g. a court) as evidence that the conversation took place, how
can Eve prove that the integrity protection is intact, without
simultaneously proving that she has all the necessary information to
have forged it?

A paper on the security properties of OTR [2] points out that an
attacker with control over the network can cast doubt on this feature in
any case, by preventing third parties from actually receiving the
expired MAC keys.

> * 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).

XTLS does not, in fact, provide this. If you want non-repudiability for
a particular message, you need to perform an operation on that message
(a digital signature) with the long-term key.

I don't think non-repudiability is as important for Telepathy as the
other things listed here. It is perfectly reasonable to hope for your
instant messaging session or VoIP call to be "off the record",
tamper-evident etc., but it is not clear to me that it is desirable to
make ordinary IM contain binding statements. If you want to "enter into
a contract", do something analogous to putting it in writing - e.g. PGP-
or S/MIME-signed e-mail. (And, when you do that, follow all the same
best-practices you would when you signed a paper document - like
including the date of signing, and enough information to make it
unambiguous what your signature means, in the signed part.)

So, I consider non-repudiability to be out of scope, at the moment.

> * Strong authentication: Alice can know that the peer she is
>   communicating with is actually Bob.

In general, strong authentication cannot be done transparently: we need
interaction with the user (or, at least, their trusted storage for
pinned certificates), analogous to the Chan.T.ServerTLSConnection we use
to authenticate the XMPP server itself.

In simple cases it might be possible to obtain encryption, integrity and
weak authentication non-interactively, and then "upgrade" an ongoing
session to be strongly authenticated by performing the interactive
strong authentication step later.

However, this assumes that the connection manager can choose a
medium-term or long-term credential (self-signed certificate for XMPP,
keypair for OTR) non-interactively. I'm not sure whether this is
actually true.

> * 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.

> * 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

I don't think either weak or strong anonymity is as interesting for
Telepathy as the other properties here: one of our central assumptions
is that identifying people by their XMPP JID (or equivalent) is useful
and makes sense. If that's not the case, then for a start, contact lists
(the XMPP roster) are pretty worthless.

Being securely anonymous is hard: for a start, you have to worry about
traffic analysis, including correlation between the timing of your
anonymous and non-anonymous traffic (and that's just to defend against
passive attackers!). I don't think I want Telepathy to try to guarantee
that it will preserve your anonymity without a significant amount of
analysis, so at the moment I consider anonymity to be out-of-scope.

If we do later support secure anonymity, I anticipate that to be useful,
it would have to be a global setting influencing all sorts of things:
"make sacrifices for anonymity, y/n".

References
----------

[1] "XEP-0027: Current Jabber OpenPGP Usage". XSF.
<http://xmpp.org/extensions/xep-0027.html>
[2] "Finite-State Security Analysis of OTR Version 2". Joseph Bonneau
and Andrew Morrison. <http://www.jbonneau.com/OTR_analysis.pdf>