Hi Jonathan! Jonathan Wilkes <[email protected]> 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
signature.asc
Description: OpenPGP Digital Signature
_______________________________________________ Freedombox-discuss mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss
