<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div><span>Hi Bjarni,</span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>Thanks for the response.<br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span><br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>Does your design include perfect forward secrecy for the pairs communicating over SMTorP?</span></div><div style="color: rgb(0, 0, 0);
font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><span>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.)<br></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif; background-color: transparent; font-style: normal;"><br><span></span></div><div style="color: rgb(0, 0, 0); font-size: 16px; font-family: HelveticaNeue,Helvetica Neue,Helvetica,Arial,Lucida Grande,sans-serif;
background-color: transparent; font-style: normal;"><span>-Jonathan</span></div> <div class="qtdSeparateBR"><br><br></div><div style="display: block;" class="yahoo_quoted"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font size="2" face="Arial"> On Sunday, October 19, 2014 7:08 AM, Bjarni Runar Einarsson <bre@pagekite.net> wrote:<br> </font> </div> <br><br> <div class="y_msg_container">Hi Jonathan!<br clear="none"><br clear="none">Jonathan Wilkes <<a shape="rect" ymailto="mailto:jancsika@yahoo.com" href="mailto:jancsika@yahoo.com">jancsika@yahoo.com</a>> wrote:<br clear="none">> Hi Bjarni,What is the novel part of your SMTorP design that allows users<br clear="none">> of insecure email to "gradually, opportunistically" improve
their<br clear="none">> security wrt hiding their metadata?<br clear="none"><br clear="none">The incremental improvements are not part of the design of SMTorP, but<br clear="none">part of how we intend to use it.<br clear="none"><br clear="none">To sum up, we are building a user friendly SMTP/MIME mail client which<br clear="none">will automatically generate PGP keys and configure a Tor hidden service<br clear="none">for "p2p style" delivery of messages directly from one client to<br clear="none">another. Keys and SMTorP addresses will be advertised in clear-text (but<br clear="none">possibly PGP signed) e-mail (and/or in DNS and/or on the user's PGP key,<br clear="none">...) 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.<br clear="none"><br clear="none">Using
this strategy with other transports - such as Cables - is<br clear="none">perfectly feasible and might be an improvement over our preliminary<br clear="none">ideas. Longer term we want to make the transports pluggable, but our 1st<br clear="none">implementation will probably just use PGP and SMTorP to get something<br clear="none">that works and let us flesh out the user interface metaphors required.<br clear="none"><br clear="none">> It looks to me like your users<br clear="none">> would need to exchange onion addys out-of-band, or else take the risk<br clear="none">> that comes with exchanging over an insecure connection.<br clear="none"><br clear="none">Yep. Considering that most e-mail is completely insecure as it is, we<br clear="none">are quite comfortable with exchanging keys and secure addresses over an<br clear="none">insecure connection, using a "TOFU" trust model. Users that need more<br clear="none">security will be given tools and
user interface elements which let them<br clear="none">manually (OOB) verify keys/fingerprints etc. - but the fact is most<br clear="none">users won't care and making that sort of thing mandatory for everyone<br clear="none">would just exclude people needlessly and perpetuate the current "nobody<br clear="none">encrypts because nobody encrypts" status quo.<br clear="none"><br clear="none">> Well, I guess<br clear="none">> they could also leverage GPG if they've already done a key exchange. <br clear="none">> But anyway, that's the same with Cables so I'm not seeing any scaling<br clear="none">> benefits that would deliver more privacy more easily to a greater number<br clear="none">> of users.<br clear="none"><br clear="none">I never claimed scaling benefits. At first glance the two systems should<br clear="none">scale quite similarly, their limitations are inherited from the scaling<br clear="none">capabilities of Tor and I2P. But being
able to scale doesn't matter if<br clear="none">you don't have a workable strategy for acquiring users in the first<br clear="none">place and I think that may be where our approaches differ.<br clear="none"><br clear="none">> (And you already listed one drawback, which is that you have<br clear="none">> to develop some kind of safeguard to keep users from mixing normal and<br clear="none">> onion addys in the same message.)<br clear="none"><br clear="none">Yes, this is one of the prices we pay for trying to incrementally<br clear="none">improve things, instead of wholesale replacing them. Wholesale<br clear="none">replacement is technically easy, but provides almost no real value to<br clear="none">the user since they have nobody to talk to.<br clear="none"><br clear="none">In any case, I suspect that any real messaging system will have to deal<br clear="none">with this or similar issues anyway, as I am very doubtful that end-user<br
clear="none">security can be meaningfully improved without user interface work. In<br clear="none">particular, you need to explain and guide the user when an attack is<br clear="none">detected, otherwise your attacker just DOSes the secure channel and the<br clear="none">user will switch to an insecure one because the secure one is "broken"<br clear="none">and they do not understand why.<br clear="none"><br clear="none">(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.)<br clear="none"><br clear="none">> Btw-- did you look at Cables before you started working on SMTorP? If<br clear="none">> so, what was it lacking? If
not, what is it lacking?<br clear="none"><br clear="none">I did not. After taking a quick look, it seems quite nice. In<br clear="none">particular, I like the fact that Cables appears to be basically e-mail<br clear="none">with a well thought out, more secure transport layer. It would be fun<br clear="none">to add native Cables support to Mailpile once we have our Tor<br clear="none">integration working correctly.<br clear="none"><br clear="none">Compared with SMTorP, Cables invents a whole bunch of new stuff which we<br clear="none">decided to just inherit from existing systems. Our goal was (and is) to<br clear="none">implement the simplest possible thing which protects the user's metadata<br clear="none">and cuts out as many middle-men as possible. So we re-use Tor, SMTP,<br clear="none">TLS, MIME and PGP. This gives us a vast trove of existing, mature<br clear="none">software to work with and SMTorP development largely becomes a matter of<br
clear="none">configuring things correctly. We considered this a major benefit to the<br clear="none">SMTorP approach.<br clear="none"><br clear="none">Hope this clarifies!<div class="yqt4457873285" id="yqtfd85887"><br clear="none"> - Bjarni</div><br clear="none"><br clear="none">-- <br clear="none">I make stuff: www.mailpile.is, www.pagekite.net<br><br></div> </div> </div> </div> </div></body></html>