[Freedombox-discuss] Idea for cross freedombox email system not leaking metadata
Hi Bjarni,
Thanks for the response.
Does your design include perfect forward secrecy for the pairs communicating over SMTorP?
Also, what is your plan to sustainably fund the GUI work, user studies, and the work on professional documentation? (I.e., those aspects which tend to get little to no attention in a free software community like this one.)
-Jonathan
On Sunday, October 19, 2014 7:08 AM, Bjarni Runar Einarsson <bre at pagekite.net> wrote:
Hi Jonathan!
Jonathan Wilkes <jancsika at yahoo.com> wrote:
> Hi Bjarni,What is the novel part of your SMTorP design that allows users
> of insecure email to "gradually, opportunistically" improve their
> security wrt hiding their metadata?
The incremental improvements are not part of the design of SMTorP, but
part of how we intend to use it.
To sum up, we are building a user friendly SMTP/MIME mail client which
will automatically generate PGP keys and configure a Tor hidden service
for "p2p style" delivery of messages directly from one client to
another. Keys and SMTorP addresses will be advertised in clear-text (but
possibly PGP signed) e-mail (and/or in DNS and/or on the user's PGP key,
...) and a TOFU model will be used to upgrade the security of a pairwise communication channel in an opportunistic manner. That's the rough idea anyway, we are still hard at work and this vision is not fully realized by our existing code base.
Using this strategy with other transports - such as Cables - is
perfectly feasible and might be an improvement over our preliminary
ideas. Longer term we want to make the transports pluggable, but our 1st
implementation will probably just use PGP and SMTorP to get something
that works and let us flesh out the user interface metaphors required.
> It looks to me like your users
> would need to exchange onion addys out-of-band, or else take the risk
> that comes with exchanging over an insecure connection.
Yep. Considering that most e-mail is completely insecure as it is, we
are quite comfortable with exchanging keys and secure addresses over an
insecure connection, using a "TOFU" trust model. Users that need more
security will be given tools and user interface elements which let them
manually (OOB) verify keys/fingerprints etc. - but the fact is most
users won't care and making that sort of thing mandatory for everyone
would just exclude people needlessly and perpetuate the current "nobody
encrypts because nobody encrypts" status quo.
> Well, I guess
> they could also leverage GPG if they've already done a key exchange.
> But anyway, that's the same with Cables so I'm not seeing any scaling
> benefits that would deliver more privacy more easily to a greater number
> of users.
I never claimed scaling benefits. At first glance the two systems should
scale quite similarly, their limitations are inherited from the scaling
capabilities of Tor and I2P. But being able to scale doesn't matter if
you don't have a workable strategy for acquiring users in the first
place and I think that may be where our approaches differ.
> (And you already listed one drawback, which is that you have
> to develop some kind of safeguard to keep users from mixing normal and
> onion addys in the same message.)
Yes, this is one of the prices we pay for trying to incrementally
improve things, instead of wholesale replacing them. Wholesale
replacement is technically easy, but provides almost no real value to
the user since they have nobody to talk to.
In any case, I suspect that any real messaging system will have to deal
with this or similar issues anyway, as I am very doubtful that end-user
security can be meaningfully improved without user interface work. In
particular, you need to explain and guide the user when an attack is
detected, otherwise your attacker just DOSes the secure channel and the
user will switch to an insecure one because the secure one is "broken"
and they do not understand why.
(It appears that Cables has not yet given the user interface much thought, as you list as a "benefit" that it works transparently with an unmodified mail client - an assertion that sets off warning bells in my UI-focused mind since it means your user-interface is at best based on "Message Delivery Reports" to be read by humans - something I have never seen work well.)
> Btw-- did you look at Cables before you started working on SMTorP? If
> so, what was it lacking? If not, what is it lacking?
I did not. After taking a quick look, it seems quite nice. In
particular, I like the fact that Cables appears to be basically e-mail
with a well thought out, more secure transport layer. It would be fun
to add native Cables support to Mailpile once we have our Tor
integration working correctly.
Compared with SMTorP, Cables invents a whole bunch of new stuff which we
decided to just inherit from existing systems. Our goal was (and is) to
implement the simplest possible thing which protects the user's metadata
and cuts out as many middle-men as possible. So we re-use Tor, SMTP,
TLS, MIME and PGP. This gives us a vast trove of existing, mature
software to work with and SMTorP development largely becomes a matter of
configuring things correctly. We considered this a major benefit to the
SMTorP approach.
Hope this clarifies!
- Bjarni
--
I make stuff: www.mailpile.is, www.pagekite.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/freedombox-discuss/attachments/20141019/624b5f1d/attachment.html>
Reply to: