Re: [tor-dev] Proposal 236, Single-guard designs, and directory guards

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Thu, Jun 5, 2014 at 12:50 PM, George Kadianakis <desnacked@xxxxxxxxxx> wrote:
> Nick Mathewson <nickm@xxxxxxxxxxxxxx> writes:
>
>> Hi, all!
>>
>> I noticed that proposal 236 doesn't mention directory guards. (See
>> proposal 207, implemented in Tor 0.2.4.)  I think that we should
>> consider retaining multiple directory guards while going to a single
>> guard for multi-hop circuits.
>>
>> My rationale here is that when we have only a single directory guard,
>> it can more easily perform hard-to-detect route biasing attacks by
>> pretending not to have descriptors for nodes it doesn't like.  Its
>> ability to do this is limited by fact that we won't build circuits
>> unless 95% of all paths are buildable (see
>> get_frac_paths_needed_for_circuits() and its users). But still,
>> trusting a single source for the completeness and freshness of your
>> directory info is suboptimal.
>>
>
>> Hi, all!
>>
>> I noticed that proposal 236 doesn't mention directory guards. (See
>> proposal 207, implemented in Tor 0.2.4.)  I think that we should
>> consider retaining multiple directory guards while going to a single
>> guard for multi-hop circuits.
>>
>> My rationale here is that when we have only a single directory
>> guard,
>> it can more easily perform hard-to-detect route biasing attacks by
>> pretending not to have descriptors for nodes it doesn't like.  Its
>> ability to do this is limited by fact that we won't build circuits
>> unless 95% of all paths are buildable (see
>> get_frac_paths_needed_for_circuits() and its users). But still,
>> trusting a single source for the completeness and freshness of your
>> directory info is suboptimal.
>>
>
> I discussed this a bit with Roger yesterday, who helped me understand
> the issue.
>
> It seems to me that from a security prespective it makes sense to use
> our circuit guard as our directory guard (assuming that it's a
> DirCache). This is to minimize our network fingerprint, and we also
> trust our guard to not selectively deny EXTEND requests anyway (which
> is a form of a path bias attack).
>
> So, IIUC, the path bias attack Nick is worrying about is:
> a) Client fetches consensus from dirguard.
>
> b) Client walks consensus and asks the dirguard for router
>    microdescriptors in batches.
>
> c) The attack is that a dirguard can now selectively claim that it
>    doesn't have some microdescriptors, in an attempt to influence the
>    path selection of the client.

That's the idea.

We should also reconsider the way that compute_frac_paths_available
should work in a 1-guard world.  Do we want to keep the requirement as
"don't build circuits until you have the microdescriptors necessary to
build X% of the paths through the network?" Or should we change it to
require X% of all paths _through your guard_?  Or raise the X?

> The attack is not a big problem in the current architecture, since the
> client will go ahead and ask another directory guard for the missing
> descriptors. However, it becomes a problem when we have a single
> directory guard since there is no one else to talk to.
>
> IIUC, the problem stems from the fact that even honest directory
> servers might not have the microdescriptors that a client asks for:
>
> This might happen when a dirserv fetches a new consensus from the
> auths, the new consensus contains some unknown routers, and the
> dirserver hasn't fetched the descriptors for these unknown routers
> yet. So there is a race condition between the dirserv fetching a
> consensus, and the dirserv downloading all the missing descriptors,
> during which it will serve a consensus containing routers that it
> doesn't have the descriptors for.
>
> Are there other legitimate cases where an honest directory server can
> claim to not have a descriptor?

Maybe it can't get it from the authorities for some reason.  (Like,
when it tried to fetch descriptors, one download failed, and it hasn't
retried yet.  Or it asked an authority that doesn't know about a given
microdescriptor yet (because the authority didn't vote for that one),
and it hasn't retried yet.

> If the above is the only case, we can fix it by making sure that
> directory servers start serving a consensus _only after_ they have
> downloaded the descriptors of all the routers mentioned in that
> consensus.

In spite of what I say below, this behavior or something like might
actually be a good idea. (needs-proposal.)

> If the above behavior is applied, it means that honest directory
> servers don't have any excuse for not having a descriptor mentioned in
> a consensus they just served. Hence, a directory server that claims
> that, is an evil directory server.
>
> But that's too easy, isn't it?

I think so.  It would break an assumption in our current directory
model, and breaking assumptions like that (that directories are
allowed to not know things) make me a bit nervous. Also, as you note
below, clients wouldn't be able to rely on it until every directory
guard has updated.

> I wonder how the above idea interacts
> when multiple consensuses are valid at the same time. And also if the
> above idea gets implemented, non-upgraded directory servers will be
> flagged as evil by upgraded clients.
>
> .oO(I wonder how frequent it is for an honest dirguard to not have the
> descriptors a client is asking for.)
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev