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

[Tom Ritter]

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.

> Traffic correlation between sender and receiver is easier than it
> would be in a store-and-forward system.

I think this is only true if you assume a network observer has limited
time-based observability, the lack of desire to do any correlation,
and the store-and-forward system performs no mixing.

> 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? And that if
you don't run your own, the server learns whether or not you are
retrieving  mail you recieve?

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.)


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

Taking Hidden Services at their face, as a protocol with properties
just like TLS is a protocol with properties, Hidden Services is better
than TLS, and its failure mode is no worse.



> For unlinkability of users with each other, the correlation of packet
> timing and sizes between sender and recipient needs to be broken.  In
> Pond, clients retrieve padded data from their mailbox server at a
> roughly constant rate.  Hidden Services don't help with this.

Exactly.  The strongest padding must be done at the application layer,
not the Transport Layer.  The transport layer can't know (absent an
API and storng coupling) what padding should look like for a given
application.  (My attempts to get TLS 1.3 to support padding
notwithstanding.)



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 sounds like Bjarni and SMTorP has their head in the right place
with regards to those.

-tom

PS A somewhat related tangent is that with 'Web 2.0' (or are we at 3.0
yet?) web 'clients' are essentially servers for as long as the tab is
kept open.  And the real-time updates provided by Facebook/Gmail/etc
(even Github I think...) encourage people to keep their tabs open.
(Never mind IRC and IMAP Mail Clients.) You, as a person with
knowledge of a target's online social media accounts/email address,
can cause arbitrary amounts of data to be pushed at _clients_ in many
situations now also.