Opened 5 years ago

Last modified 5 months ago

#13908 new enhancement

Make it safe to set NumDirectoryGuards=1

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: needs-proposal, tor-client, needs-design guards client-enumeration research-program
Cc: Actual Points:
Parent ID: #21006 Points:
Reviewer: Sponsor:

Description

Currently we have NumEntryGuards=1, which mitigates the "you expose your 3-hop circuits to too many relays" issue, but we still have NumDirectoryGuards=3, which means the "you have a unique guard fingerprint with respect to a local network observer" issue remains.

We should reduce NumDirectoryGuards to 1, but that's hard for now because, as Nick has pointed out, an attacking guard can withhold certain descriptors from a client to influence its path selection and thus harm its anonymity.

My first thought for a fix to that issue is that if you can't get all the microdescriptors you want from your guard, you should drop it and find a new one. But I think that could produce some really bad behavior network-wide if there are some microdescriptors that are hard to find in the network, or if there are race conditions where a consensus lists a relay but the guard doesn't quite have the microdescriptor for it yet so all its clients jump ship. Yuck.

My second thought for a fix is that if you can't get all the descriptors you want, but you can get some, then you could make a two-hop circuit through your guard to another relay, and ask it for the descriptors. That sounds great, except your guard could say "sorry that one's unreachable" and end up influencing which ones you can ask questions to, ending up with a variant of the original attack.

Nick suggested an extension of this idea where you try asking a few relays indirectly (using 2-hop circuits) and if you still can't get all your microdescriptors then you add another directory guard directly. I think that leads to the research question: how often does that situation happen naturally?

Specifically, if you pick three directory guards right now, what is the probability distribution over fetching a given fraction of the microdescriptors from the consensus? I can't imagine you'll get 100% of them consistently.

Once we have some expected threshold that we reach pretty consistently, should we call that good enough, since it matches what we get right now currently? Or should we worry that one guard could somehow cause the missing descriptors to be more precisely chosen than in the current design?

Another idea I had was to extend from the guard to a directory authority, since surely those won't all be down. That's sort of sad to make a bottleneck though.

Yet another idea is to do a three-hop circuit, so the guard doesn't know the chosen third hop. That ties directly into the path-bias field I guess.

Taking a step back: how about a simpler design where you do a 2-hop circuit through your guard, and you try like n=10 of them, and so long as k=3 of the extends succeed, you believe that the microdescriptor is indeed hard to get, and otherwise you ask another directory guard directly?

Lots of options -- somebody should analyze them, and ideally show that one of the simpler ones is adequate.

Child Tickets

Change History (9)

comment:1 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:2 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:3 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:4 Changed 3 years ago by nickm

Keywords: needs-design guards client-enumeration research-program added
Severity: Normal

comment:5 Changed 2 years ago by arma

Parent ID: #21006

comment:6 Changed 22 months ago by arma

Another piece of moving to just one directory guard: right now relays will return a 503 if they're running low on bandwidth in their token buckets. The idea is it's fine to shed load and push it somewhere else in the network that can handle it.

But if we have guards who have run out of bandwidth and they're serving a bunch of 503's, this won't be any fun for the clients who use those guards.

comment:7 Changed 22 months ago by teor

In particular, our missing microdesc mitigations only work because there are multiple directory guards. We'll need to implement some of the more serious fallback strategies under #23863 to move to one directory guard.

comment:8 Changed 20 months ago by arma

What do we think about moving to 2 dir guards? We identified problems with 1, and different problems with 3. Do we get the best of both worlds with 2, or the worst of both worlds? :)

comment:9 Changed 5 months ago by cypherpunks

suggests until there is 2-hop circuits fallbacks for dirfetch, setting NumDirectoryGuards=2 in consensus to get further this issues?

Note: See TracTickets for help on using tickets.