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

[Trevor Perrin]

On Mon, Jun 16, 2014 at 6:53 AM, Tom Ritter <tom at ritter.vg> wrote:
> I think you should point out that we're talking about asyncronous
> protocols. Comparing syncronous HS-based chat protocols with
> asyncronous email-like store-and-forward protocols is apples and
> oranges.

We're sort of talking about turning asynchronous, email-like protocols
*into* synchronous protocols.  Which I'm skeptical about.


>> So a store-and-forward system with many users sharing the same mailbox
>> server seems better.  This is how Pond works
>
> I thought Pond let/encouraged you to run your own mailbox?

Dunno about "encouraged".  The constant traffic pattern between
recipient and mailbox helps obscure the relationship between senders
and recipients.  If every recipient had a unique mailbox then that
would be ineffective, and Pond's relationship-hiding would depend only
on Tor.


> And that if
> you don't run your own, the server learns whether or not you are
> retrieving  mail you recieve?

Yup.  Though in the scheme of things, that seems like a lesser leak?


> Contrasted to Pynchon Gate which works similarly, but 'better' - your
> mailbox does sit aside many others' mailboxes guarenteed, but the
> nodes you connect to to download data from don't learn if you're
> recieving or even checking your mail thanks to PIR. (This gets you
> closer to Alt.Anonymous for the recipient, except the nymserver knows
> if your nym is recieving mail.)

Agreed that's better, if you could find multiple independent parties to run it.


> I was always a bit bemused by people's desire to run
> Mixmaster/Mixminion nodes (mostly Mixmaster) over Tor Hidden Services.
> It always seemed like this absurd bandaid: "Getting MITM-proof
> StartTLS in SMTP servers is hard: Let's just use Hidden Services!"
>
> But at the same time, I understand why.  HS provides some built-in
> features that make them attractive.  Just like using TLS gets you
> confidentiality for free, using HS gets you:
>  1 Authenticity (with no CAs!) on the link
>  2 Confidentiality of the link
>  3 Free and Easy NAT Travsersal, allowing anyone to run a server
> (Especially for Country-Wide NAT)
>  4 Some Anonymity for Client
>  5 An attempt at Anonymity for Server
>  6 'Decentralized Prescence' - login.oscar.aol.com doesn't know if a
> server is online, one must poll and reveal the connection attempt, to
> determine prescence
[...]
>
> Choosing Hidden Services as a Transport Layer makes sense, if only for
> #1-3.  Getting 4-6 for free is even better.  The problem is really if
> people are relying on, or advertising 4-6.

It's going to be hard to communicate that.  If you tell people they're
using a fancy Tor feature so they can run a "hidden" thing that
doesn't reveal data to a server, they're not going to think: "oh,
that's analogous to TLS transport encryption".  They're going to
think: this is awesome, I'm invisible!


Trevor