(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> _______________________________________________ telepathy mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/telepathy
