<div dir="ltr"><div><div><div>>*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<br><br></div><div>I like this idea, but have 2 questions:<br><br></div></div>- 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)<br>
<br></div>- 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?<br>
<div><div><div><br></div><div>Best<br></div></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 6:33 PM, Joseph Bonneau <span dir="ltr"><<a href="mailto:jbonneau@gmail.com" target="_blank">jbonneau@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div>
<div><br></div><div>*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.</div>
<div><br></div><div>*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.</div>
<div><br></div><div>*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.</div>
<div><br></div><div>*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.</div>
</div><div><br></div><div>*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.</div>
<div><br></div><div>*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.</div>
<div><br></div><div>I'm not necessarily endorsing any of these viewpoints, that's my best effort to summarize the discussion.</div><div><br></div><div>Joe</div></div>
<br>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
<br></blockquote></div><br></div>