[Bug 29904] Support end-to-end encryption and authentication

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=29904

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
Feedback on ZRTP's security properties would be appreciated; it isn't entirely
clear to me what ZRTP's security model is. Please see the list of security
properties in
<http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html> for a
useful starting point: which of those properties does ZRTP-over-Jingle have?

>From a brief look at the specifications, it looks to me as though ZRTP is an
alternative to DTLS as a layer over SRTP, providing (at least) confidentiality
from passive attackers, integrity, and what I called "weak authentication" in
that email (i.e. if you trust the path followed by your XMPP messages, then you
can trust that you are talking to the peer you think you are), and perfect
forward secrecy.

It appears to have several ways to get from weak to strong authentication: PGP
or X.509 signatures, its own interactive handshake (the "short authentication
string") analogous to SMP in OTR, or ssh-style key-continuity. Which of these
are actually used in practice?

I'm not sure whether it has anonymity or replay protection. Feedback welcome.

Ideally, Telepathy UIs would not have to distinguish between ZRTP and DTLS,
except possibly by one of them having more "security feature" flags than the
other (if their security properties differ). However, it appears the
authentication handshake has to be interactive at least some of the time (as
for OTR); and if both are implemented, there's probably a need for a way to
choose whether to try to use ZRTP or DTLS, and which set of long-term
credentials (if any) to present.

Hopefully much of the Farsight work needed for DTLS+SRTP and ZRTP+SRTP, and
some of the Telepathy design needed for each of XTLS, DTLS, ZRTP and OTR, would
be the same?

One possible starting point for use of ZRTP would be to encrypt Jingle calls
opportunistically and transparently, without worrying about whether the IM
server can perform a man-in-the-middle attack or signalling that the call is
encrypted; that would not be full end-to-end security, but it would at least
get calls up to the same security status as IMs and presence ("if you trust
your server, the peer's server and the hops between them, then everything is
fine"), and it could be done in parallel with the (rather tricky) design for
how the authentication bits work, I think.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.