[messaging] SURBs

[Brian Warner]

On 6/18/14 11:11 PM, Trevor Perrin wrote:

> Is it a requirement for Alice to run her own mailbox server? I would
> expect Alice to just have an account on some server, and hope that the
> mix network + SURBs keep her from being linked with Bob or
> de-anonymized.

Well, that's the distinction I'm getting at. If Alice uses a server at
all (whether she's running it herself, or renting space on somebody
else's server), then there's a relationship between Alice and the server
that might get used to reveal her identity. Maybe she has to pay for the
space: now there's a billing record. She has to use some real-time
channel to download her messages: now there are timing correlations to
be made. And the server's identity (IP address, hence the owners) is
public, increasing its vulnerability to compromise.

(if she's using SURBs to download her messages from server1, then she
actually needs a server2 for those SURBs to point at)

I think you need one of (SURBs, Hidden Services, a realtime reverse
channel) to hide a recipient's identity, whether that recipient is
Alice's home computer, a VM she rents, or a slot on a shared server that
she rents.

It may be ok to skip this hiding because the immediate recipient (a
server) isn't the "real" recipient (Alice), but then we're depending on
the server, or one of those three technologies, to conceal the real
endpoint.

> It's interesting you're not proposing a "nymserver" here, which I
> thought was the classic idea (i.e., Alice gives Bob her email address
> "pseudonym at nymserver.com", Alice contacts the nymserver over the mix
> net to keep it supplied with SURBs, and one of them is used to relay
> Bob's message.)

Heh, I'd actually forgotten about nymservers. They're super-useful for
allowing messages in from the "legacy" SMTP world (sender doesn't care
about privacy and won't install new software, but recipient does), but
we're mostly talking about closed systems.

> I assume that's because you want to limit nym -> Alice traffic for
> security reasons, so it's safer to dole out SURBs in small quantities
> to correspondents?

Yeah, small quantities limits the "burst of traffic" attacks that could
be mounted to try and discover the location of the recipient
(network-enforced rate-limiting). Giving SURBs to senders might also let
you limit DoS/spam by previously-approved senders, but if we aren't
running into a resource limitation somewhere, I'd just make the system
accept everything and have the final MUA decide whether to display the
message or not.

> Or at least, it's nice to solve easier problems on the way to harder
> ones.

Yeah. I guess we should address the "two people who know each other get
to communicate securely" case before trying to tackle the case where one
of them doesn't know the other.

> - How does Alice introduce herself to Bob; a premise of Pond / Petmail
>   is the introduction step to exchange delivery tokens, so mailboxes
>   don't have to choose between rejecting traffic from anonymized
>   senders or getting killed by spam/abuse. If you can't limit
>   spam/abuse this way, it's not clear what you replace it with.

I think I'm saying that the introduction step gives delivery tokens to
Alice, but doesn't necessarily reveal Alice's identity to Bob (imagine
the journalist getting an invitation code-word along with the bundle of
secret documents slipped under their door). Bob can still limit traffic
to senders with valid tokens, despite knowing nothing else about them.

cheers,
 -Brian