[messaging] Tor Hidden Services in (Cables, SMTorP, Pond)

[Brian Warner]

On 6/22/14 2:18 AM, Bjarni Runar Einarsson wrote:

> I tend to assume the relay is a potential adversary, which is an
> assumption folks may not agree with, but is supported by history and
> the current state of the network.

Yeah, I think of relays as semi-trusted: you're willing to give up
certain things in exchange for certain benefits. In this case, you give
them some measure of control over your availability (they might
drop/corrupt a message), and maybe you enable them to learn more about
your message timing than the rest of the world, in exchange for which
they usually improve your availability (by queueing messages, so you
aren't limited to having both sender and receiver online at the same
time, and the receiver having a public IP address).

If we do the protocol right, you don't give up any more than that.

> If I can tell people "with SMTorP you no longer have to wonder when
> the mail was delivered or whether it ended up in their spam folder",
> then many will switch for that reason alone.

That's a great selling point! I think you're absolutely right that we
have to sell new systems on qualities that people really care about, and
security is not one of them.

> This is one of the main reasons I'm really not keen on relays. They
> kill the usability benefits I am shooting for, add back all the old
> shit from legacy SMTP and add another potential point of compromise
> and attack.

I think a lot of those problems can be addressed by the right protocol.
The spam-filtering problems go away (because messages are encrypted: the
server couldn't do content-filtering even if it wanted to). We can
tolerate unreliability with agent-to-agent ACKs and retransmits without
needing to reveal if/when a human has seen the message.

The high-order issue remains, of course: how do you get in touch with a
stranger, and also deter spam. But it's the recipient's agent which
enforces this, not the relays, which I think gives senders the minimum
possibly level of uncertainty.

> Since SMTorP addresses are just something at foo.onion, if you use a
> receive relay then the relay operator owns your e-mail address, making
> him a middle man you cannot get rid of without changing addresses and
> notifying all your contacts.

In Petmail, I dealt with this by making the transport channel(s) merely
a property of the contact record, rather than being the primary
identifier (which is just a public key). You need to have at least one
transport so people can send messages to you, but you can have more than
one, and if somebody's giving you bad service, you just rent a new one
and replace them. Your list of current transports gets sent to each new
correspondent during the invitation process, and your agent updates
their agents automatically when it changes.

cheers,
 -Brian