[messaging] Summary of discussion session at USENIX HotSec

[Wasa Bee]

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

I like this idea, but have 2 questions:

- E2E support does not necessarily mean user awareness of the feature. How
do you bootstrap user awareness of such feature? Should you also ask the
EFF to push large providers to develop such anonymous mechanisms to access
certain sensitive services, e.g. like "Alcoholics Anonymous", sexual
harassment services, birth control hotlines, HIV hotlines, etc for which
people want to remain anonymous. Would this be a good starting point to
sensitive people about the importance of "anonymity" and privacy in
general, in order to bootstrap "user awareness". Or do you imagine that E2E
services would be enabled by default (i.e. not opt-in - which I believe
would be very unlikely)

- more importantly, is there a successful business model one can build when
not having access to user data? What shall it look like? Having plug-ins
available and good UI is important, but to reach a large audience, someone
has to make a living out of it somewhere.... was there any discussion on
that?

Best


On Wed, Aug 20, 2014 at 6:33 PM, Joseph Bonneau <jbonneau at gmail.com> wrote:

> 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
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140820/4d8e7a2b/attachment.html>