Hi Bjarni, all, Good points, the discussion touches a lot of things:
1) Receiving messages via self-hosted Hidden Services 2) Servers running as Hidden Services 3) Low-latency (Tor) vs high-latency anonymizing systems I'll only get to (1) here, maybe the others later... Bjarni argues there's value in avoiding the existing email infrastructure, to "cut out all the middle-men who might listen in, mis-classify as spam, arbitrarily delay or otherwise interfere with your mail". I'd argue the "listen in" part is solved by encryption. For the rest: if this is a problem with your provider you could get a new provider. Having your average user run an SMTP Hidden Server at home doesn't seem like it would improve reliability vs commercial services, considering spam, hacking, ddos, machine and network uptime, the Tor dependency, etc. But it's possible existing mail providers won't be amenable to widespread encryption that removes their ability to see spam / viruses / ad keywords, or widespread identity/relationship-hiding. So perhaps the premise behind (SMTorP, Cables, Pond, etc) is correct, and we need new protocols and infrastructure. In that case, I'd still argue the "sender -> recipient mailbox" model is better than the P2P "direct contact" model. In addition to the useability / reliability / security issues with self-hosted services - which are substantial - I think the intuition that "direct contact" improves privacy is untrue in important ways. Consider the different sorts of information to hide: Contents - encryption Identity - anonymity, pseudonymity Relationships - who are you in contact with Presence - when are you online Volume - how many messages you receive, and when Let's look at how these are differently exposed in the "mailbox" vs "direct contact" models: Contents - end-to-end encrypted, no difference. Identity - A mailbox server can be accessed over Tor, with traffic padding (like Pond) to break correlation with sent messages. In contrast, a self-hosted hidden service makes it easy for anyone monitoring your link to de-anonymize you by sending a distinctive traffic pattern. Also, uptime-monitoring leaks some information. Bjarni suggests that if you "are more or less always online, then the fact that your Tor hidden service is reachable leaks no information". But "more or less always" is not "always" - there will be power and network outages, and machine upgrades and moves, which over the long term could be quite revealing. Relationships - Against traffic analysis the mailbox model is better, since an observer can't look for traffic correlation directly between sender and recipient, or correlate the sender's polling loop with recipient downtimes. While these risks could be eliminated (high-latency remailers, always-on recipient servers), the only advantage for the direct-contact model is if identities are not end-to-end encrypted, which they should be. Presence - Direct contact requires you to advertise server uptime to the world. If the server's your laptop, this leaks a lot about your activities. Though I admit: if your self-hosted server is always-on, direct-contact has the advantage that it doesn't reveal to a mailbox when you download messages. Volume - A mailbox learns the volume of messages you're receiving, but if accessed cleverly (like in Pond) can hide this information from someone observing your network link. A direct-contact server reveals this to a network observer. So I think that for hiding identity and relationships, the "layer of indirection" provided by a mailbox server is better. For hiding presence, direct-contact is better only if you run an always-on server (unrealistic for most users). For hiding volume, it depends on the threat (would you rather reveal this to a server you can choose, or the network you happen to be on). Anyways, I guess I'm still not sure there's enough privacy or other benefit to self-hosted, direct-contact servers to justify the deployment challenges. Trevor On Sun, Jun 15, 2014 at 1:07 PM, Bjarni Runar Einarsson <[email protected]> wrote: > Hey Trevor, everyone, > > Thanks for taking a look at SMTorP! > > The points you raised in your previous mail are quite valid - real-time > p2p communication has very different properties from store-and-forward > based systems and is vulnerable to different classes of attacks and > different types of abuse. > > For some users, real-time direct delivery of messages may leak too much > information. It may also be too unreliable, if schedules don't match and > people aren't online at the same time often enough for the message > exchange to actually take place. > > However, for many the opposite is true. If you are not concerned with > anonymity and are more or less always online, then the fact that your > Tor hidden service is reachable leaks no information and you reap quite > measurable benefits from being able to cut out all the middle-men who > might listen in, mis-classify as spam, arbitrarily delay or otherwise > interfere with your mail. Today sending e-mail is a like a lottery with > very good odds - usually you win, and usually the message delivered. But > not always, and when you lose there is no feedback at all. Mail just > disappears, thanks to spam filters everywhere. If we can address that > problem and improve security at the same time, then we've improved > e-mail quite significantly. > > I think the fact that we are using Tor and Tor hidden services for this > sometimes confuses people, as it leads to the assumption that anonymity > must be one of our primary goals. But that is not actually the case. > SMTorP is primarily focused on decentralization and establishing secure > and private channels over which users exchange normal, non-anonymous, > e-mail. Just like with regular e-mail, if used carefully, anonymity may > be achieved, but that isn't our main goal here. > > I am quite excited about SMTorP, because although it is not perfect, it > is very easy to implement and deploy and it can be configured for both > scenarios - p2p or store-and-forward. So if you need anonymity or high > availability, you use a shared relay or even a sequence of relays. If > you want to be sure that you are communicating directly without any > middle-man, you run the hidden service yourself. > > My greatest concern about the p2p mode of SMTorP is actually the classic > sysadmin concern that an exposed service is more vulnerable to direct > attacks - if you run a Tor hidden service then people can connect to > that and try to break it. Who needs timing attacks, if they can just > 'sploit your Mailpile's built-in SMTP server and read all your mail? > But hey, fixing that is a mere matter of programming, right? ;-) > > Cheers! > - Bjarni > > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging > _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
