[liberationtech] Secure Email Survey

[carlo von lynX]

First of all thank you for picking up this important topic -
it's the kind of outcome out of the PGP criticism I had hoped
for. Congratulations on the insight and depth of the questions
in the form - looks like a better and more comprehensive survey
than my tentative comparison page.  :-)

The reason I am writing is because I sense that looking at the
e-mail use case by itself can favor suboptimal solutions. The
discussions of the last few days have gotten me thinking of
three imperfections in the design of Pond.

No doubt Pond is a much much more advanced solution than PGP
over e-mail, but still it has a centralized approach to
shared secret rendez-vous which I hope can in future be
resolved nicer with a privacy preserving DHT such as GNS
(there's also the possibility to exchange keys in armor,
 if you already have a secure channel via OTR or PGP)

And the other aspect is that each and every message goes to
a Pond server. There is no optimization when two people are
online at the same time and could actually have a real-time
conversation. In a way that is intentional: An asynchronous
Pond dialogue is much harder to trace. On the other hand
those Pond servers, although they have no idea what they are
hosting and for whom, have long term hidden service addresses
and could become subject to traffic analysis over an extended
period of time. Still nothing worth being concerned about -
Pond has the most advanced privacy strategy I've seen - yet
when two people are having a real-time exchange anyway, Pond
should be able to make use of such an existing channel, skip
the server involvement and deliver the message directly to
the counterpart. That implies a tighter integration with
other communication tools.

The third aspect is group communication. Pond provides none,
which is even less than PGP/SMTP.

To cut a long story short: Asynchronous messaging would find
a more advanced solution if looked at in a broader perspective
of synchronous data exchange, multiparty data exchange and in
particular scalable multiparty data exchange: None of the new
and shiny obfuscated messaging systems would be able to timely
serve a news announcements to thousands of recipients. Let
alone the numbers Twitter and Facebook deal with.

You may think - but if several thousands are going to receive
that message, why does it have to travel over a secure email
system? Because the fact that you are registered to receive
this message is politically relevant.

That's why when looking at alternatives for asynchronous
messaging I think one should also keep an eye on the
synchronous messaging and chat, at the social networking
functionality and at the distribution scalability strategy
of the entire architecture.

Things like Pond are a great solution for today, to have at
least a bunch of relevant use cases outside the reach of the
man in the middle. But if anyone was thinking we could reach
out for something like a future secure mail standard, for
that I am writing this note of warning. We need a much more
advanced and complex solution to become the next messaging
standard for the world. Something none of the existing apps
are even close to providing.


On Mon, Nov 25, 2013 at 03:01:57PM +0000, Dan Meredith wrote:
> All these projects are working on email or email-like communication that
> departs from traditional encrypted OpenPGP or S/MIME email in one way or
> another. Although this survey only applies to asynchronous messages
> (i.e. not synchronous chat), there is a great deal of diversity among
> the approaches. Some projects are open source, some are not. Some

We cannot recommend and should not finance anything that we
don't have the source codes for.

> projects provide services, some provide only software. There are
> centralized, federated, and peer-to-peer approaches. There are HTML5
> apps, desktop apps, mobile apps, and extensions. You get the idea.
> 
> Please let us know if we are missing any projects.

I would add liberte' cables (http://dee.su/cables) and the I2P
messaging methods (Susimail, I2Pbote I believe).

> Is the project email or email-like (or both)? In other words, does it use SMTP?
>  - It uses SMTP.

There was a time when e-mail was not SMTP and there is no
reason why those two terms need to converge. SMTP is the
part of the e-mail architecture that needs replacement the most,
whereas RFC822, POP/IMAP and PGP may still have a role in
a future e-mail system (although I have criticism for each of
these building blocks).

> Do you also provide service using your software? (For example, do you provide email accounts for users? This question does not apply, obviously, for p2p projects).
>  - No

Hm, federation is so commonly expected to be the normality that
any distributed system is filed under "p2p" even if, like Tor, it
runs on thousands of servers, thus rather distant from what "p2p"
was supposed to mean. Tor started as P2P, but I think it isn't
anymore. I2P is heading in the same direction and I expect the
same from RetroShare and GNUnet.