Re: [tor-dev] Proposal 259: New Guard Selection Behaviour

On 25 Mar 2016, at 00:31, George Kadianakis <desnacked@xxxxxxxxxx> wrote:

Tim Wilson-Brown - teor <teor2345@xxxxxxxxx> writes:

[ text/plain ]

On 24 Mar 2016, at 22:55, George Kadianakis <desnacked@xxxxxxxxxx> wrote:

- How exactly should directory guards work? Should the guard lists be
initialized only with directory guards? Or should we just initialize our
guard lists from the set of all guards, and just skip non-V2Dir guards
whenever we need to make a directory circuit? FWIW, there are currently 2076
guards, out of which 1659 support V2Dir (i.e. they are directory guards).

The number of directory guards will increase when 0.2.8-stable is released and relays and clients upgrade.
In 0.2.8, relays accept tunnelled directory connections even if they do not have an open DirPort.

Indeed, soon enough all guards will be directory guards.

Almost all guards will be directory guards. AccountingMax can disable tunnelled directory fetches, as can DirCache 0.

General proposal feedback:

The proposal would be much clearer if DYSTOPIC_GUARDS was defined precisely.
Are they guards that have a DirPort 80 and ORPort 443?
Or can these ports be swapped? (DirPort 443 and ORPort 80?)

Indeed, pinning down the concept of DYSTOPIC_GUARDS in the proposal seems like
a good idea.

I think the current idea is that they are guards that have their ORPort on
ports 80 or 443. We don't care about the DirPort I think, since directory
requests happen over the ORPort with BEGIN_DIR. Is that right?

Almost all clients tunnel connections over the ORPort, some obscure configs use the DirPort.

(We want to fix this in #18483.)

Relays fetch directory documents over HTTP.

I think Reinaldo et al. were also thinking of incorporating the
ReachableAddresses logic in there, so that DYSTOPIC_GUARDS changes based on the
reachability settings of the client. I'm not sure exactly how that would work,
especially when the user can change ReachableAddresses at any moment. I think
we should go for the simplest thing possible here, and improve our heuristics
in the future based on testing.

I suggest that we compose the set of UTOPIC guards based on addresses that are reachable and preferred (or, if there are no guards with preferred addresses, those guards that are reachable). I suggest that we use the same mechanism with DYSTOPIC guards, but add a port restriction to 80 & 443 to all the other restrictions. (This may result in the empty set.)

We already accept that that set of guards can change when the consensus changes (they can disappear, or lose the guard flag).

Therefore, it seems trivial to also allow guard set changes when ReachableAddresses or similar options change.

Feedback on specific sections:

Under dystopic conditions (when a firewall is in place that blocks
all ports except for potentially port 80 and 443), this algorithm
will try to connect to 2% of all guards before switching modes to try
dystopic guards. Currently, that means trying to connect to circa 40
guards before getting a successful connection. If we assume a
connection try will take maximum 10 seconds, that means it will take
up to 6 minutes to get a working connection.

This seems far too long for most users. Usability studies have demonstrated that users give up after approximately 30 seconds.

Can we design an algorithm that will automatically choose a dystopic guard and bootstrap within 30 seconds?
What are the security tradeoffs if we do?

OK, let's assume that a connection failed timeout might take up to 10 seconds.

If Alice is behind a FascistFirewall and we want her to bootstrap within 30
seconds, this means that she always needs to have an 80/443 guard in her top
three choices. This means, that we would heavily prioritize 80/443 guards over
the rest, and an adversary who sets up 80/443 guards will attract more clients.

This isn't how Tor works - it tries multiple guards simultaneously.

(See below for details.)

Can we rework this calculation to take that into account?

I think the current proposal tries to balance this, by enabling this heuristic
only after Alice exhausts her utopic guardlist. Also, keep in mind that the
utopic guardlist might contain 80/443 guards as well. So if Alice is lucky, she
got an 80/443 guard in her utopic guard list, and she will still bootstrap
before the dystopic heuristic triggers.

There are various ways to make this heuristic more "intelligent", but I would
like to maintain simplicity in our design (both simple to understand and to
implement). For example, we could imagine that we always put some 80/443 guards
as our primary guards, or in the utopic guardlist. Or, that we reduce the 2%
requirement so that we go trigger the dystopic heuristic faster.

Or that tor can get a hint about which ports it can access based on which ports it used to bootstrap.

(See below for details.)

Currently, I'm hoping that we will understand the value of this heuristic
better when we implement it, and test it on real networks...

Any suggestions?

There's a whole lot of my thoughts below.

What are we protecting against?

I'm not convinced that "failing to connect to a guard" is much of an anonymity issue for clients.

It does provide a unique fingerprint to the censor, and the more guards we try from a pre-selected list, the more unique that fingerprint is.

But if client packets never get to the guard, then the client can't even be identified by the guard.

Why such a large list of guards?

Apart from the fingerprinting issue (which I think gets worse with a larger list, at least if it's tried in order), I wonder why we bother trying such a large UTOPIC guardlist.

Surely after you've tried 10 guards, the chances that the 11th is going to connect is vanishingly small.

(Unless it's on a different port or netback, I guess.)

And if our packets are reaching the guard, and being dropped on the way back, we have to consider the load this places on the network.

Client Bootstrap

The proposal ignores client bootstrap.

There are a limited number of hard-coded authorities and fallback directories available during client bootstrap.

The client doesn't select guards until it has bootstrapped from one of the 9 authorities or 20-200 fallback directories.

Bootstrap / Launch Time

The proposal calculates bootstrap and launch time incorrectly.

The proposal assumes that Tor attempts to connect to each guard, waits for failure before trying another. But this isn't how Tor actually works - it sometimes tries multiple connections simultaneously. So summing the times for individual connection attempts to each guard doesn't provide an accurate picture of the actual connection time.

When bootstrapping in 0.2.7 and earlier, tor will try an authority, wait up to 10 seconds for it to fail, then try another.

Then there's a 60 second wait before the third authority, but at that point the user has likely lost interest.

In 0.2.8, tor connects to authorities and fallbacks concurrently. It will try 3 fallbacks and 1 authority in the first 10 seconds, and download from whichever one connects first So 0.2.8 is far more likely to connect within a few seconds.

In all current versions, tor then downloads the consensus (~1.5MB, could take 10 seconds or more), and chooses directory guards.

Then it simultaneously connects to 3 directory guards to download certificates and descriptors.

The time it takes tor to work out if a connection to a directory guard has succeeded happens simultaneously with other directory guard timeouts.

So under this proposal, it would really take tor:

10 seconds for initial bootstrap

20 seconds (or more) to download the consensus

600 seconds / 3 directory guards = 200 seconds to exhaust its UTOPIC guardlist

(tor skip the first two phases if it has a live consensus)

Can we revise the proposal to take this into account?

Other Considerations

We're considering increasing the 10 second stream attach timeout to support users on slow and unreliable network connections (#16844). We should think about the impact of that on this proposal - I'd hate to double the time it takes tor to exhaust its UTOPIC guardlist.

Tim

Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP 968F094B

teor at blah dot im
OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail