[messaging] Summary of discussion session at USENIX HotSec

Joseph Bonneau jbonneau at gmail.com
Wed Aug 20 10:33:13 PDT 2014


Yesterday at the Hotsec workshop at USENIX security Kurt Opsahl and I
organized an unconference session on secure messaging and the EFFCUP. We
had a very good turnout of about 30 people in the room, including some
secure messaging experts and some folks who have not been following the
space closely. This was an interesting mix which provided some high-level
perspective on the best problems to work on. I was moderating and not
taking notes so this is entirely from memory, but a few interesting points
were:

*Perhaps work in this space should focus on security against a passive
adversary first, which can be done with ~0 changes to the UI (examples
include Apple iMessage and BBM Protected). In practice, this covers 90-99%
of threat models depending on who you ask. Others in the room were
uncomfortable both philosophically and practically (post-Snowden) with
accepting the ability for a central party to perform MITM attacks. The room
generally agreed it is a worthwhile goal for the EFF and others to push
large providers not providing any E2E encryption to do so, even with
centralized public key servers to start with.

*Similarly, perhaps the next step is pushing services which have adopted
E2E encryption iMessage and BBM Protected to gradually add layered UI for
users to view their public key hash and compare to their contacts. Some
ability for users to detect MITM attacks by the public key server might be
enough to discourage companies/governments from doing MITM attacks on a
large scale. Similarly, a transparency approach (as has been discussed and
beaten up a little on this list) might be a useful tool to discourage
large-scale MITM attacks.

*A popular idea was raised in the context of a potential EFF CUP
competition to mandate a very simple security profile (such as "implement
OTR") and compete on usability around that. This would lower development
costs and encourage UI innovations. Currently, perhaps too much engineering
energy is going into advanced security features when OTR already delivers
most of what most users want. If the contest involved making the best OTR
client possible, this would open the door for non-security experts to get
involved and force the innovation to be on the usability side.

*We discussed some of the challenges around group chat and why it is
fundamentally different than 2-party chat. Most of the room yawned at this
discussion. The feeling was that 2-party chat still is predominant (and
probably will continue to be). We may need stronger evidence that users
really care about multi-party chat to justify the high complexity this adds
to messaging protocols (which raises the possibility of bugs and has a real
security cost). We could also use stronger evidence of what UX users
actually want out of a multi-party chat client.

*The point was raised that lower-income individuals, especially those in
developing and middle-income countries with highly-repressive governments,
are traditionally the most vulnerable to surveillance. This may actually be
the bulk of the population around the world that could benefit from
encrypted communications. Yet most of our discussion centered around
modern, personally-owned smartphones which may not be available. More
thinking is probably needed around secure comms for folks whose only
equipment is a feature-phone, a shared/family smart-phone, or old computers
at a web cafe. JackPair was mentioned here, although of course the cost has
to decline significantly to be realistic.

*Lots of the innovation right now (examples included Axolotl and Pond)
seems to be off the academic radar. Everybody agreed it would be nice if
there was a clearer academic home for projects like this.

I'm not necessarily endorsing any of these viewpoints, that's my best
effort to summarize the discussion.

Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140820/7fdda8c0/attachment.html>


More information about the Messaging mailing list