[tor-dev] Proposal 246: Defending Against Guard Discovery Attacks using Vanguards

[Matthew Finkel]

On Sat, Jul 11, 2015 at 03:50:16PM +0300, s7r wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> I find it better to add a new consensus flag called 'Vanguard' which
> will be assigned to relays with lower requirements than the 'Guard'
> (less bandwidth, just the Stable flag). We will then select
> second_guard_set and third_guard_set from relays having 'Vanguard'
> flag. I know this could theoretically make a Sybil attack cheaper, but
> by selecting first guard, second_guard_set and third_guard_set just
> from the 'Guard' relays in the consensus, which are currently:
> 
> $ cat /var/lib/tor/cached-microdesc-consensus | grep "Guard" | wc -l
> 
> 1552
> 
> 
> would result in a less quality service for the users and it would
> hammer the existent Guards way too much.

This seems like a good idea, and was also something that was discussed.
Something we still must understand is what do we mean by "hammering". If
onion service traffic is such a small percentage of the overall network
throughput, why does it cause guard failure? When we have a better
understanding of why popular onion services are overloading their guards,
then we can better measure the tradeoffs between using distinct relay sets.

> 
> I don't think it's wise to change how we assign 'Guard' flag to the
> relays - the requirements we now have give great results for both user
> performance and load balancing.

Definitely. It's also possible the current criteria are not restrictive
enough.

> It would be better to just implement a
> second/third class of guards called Vanguards. To have a bigger pool
> of Vanguards so that the network will be better load balanced and also
> offer more diverse possible paths it is simple - remove the relays
> which are not helping at all and just eating consensus document space
> (or at least a big part of them) so the vast majority of relays in the
> consensus would be Vanguards. A Guard relay can also have the Vanguard
> flag, but if it's selected as the Guard it should not be taken in
> consideration for second_guard_set and third_guard_set. This is the
> easy part.
> 
> What requires more research is:
> 3.2 - Distinguishing new HS circuits from normal HS circuits
> 3.3 - Circuit nodes can now be linked to specific hidden services.
> 
> I see 3.2 as a worse problem than 3.3. I don't see a real fix for 3.3,
> it is by logic that if a middle node sees two HS circuits with the
> same Vanguard can assume with high probability that those circuits
> correspond to the same HS. This is just a tradeoff for this approach,
> but as I said I don't see 3.3 as a flaw. What I feel little more
> uncomfortable about is 3.2 which I think we should focus on.

But is 3.2 really important? It isn't a primary goal. We really want to make
it difficult to locate location-hidden services. Distinguishability between
different types of circuits may hurt the overall blending effect and,
therefore, may not increase the overall anonymity provided by the network, but
pinning any nodes in the circuit result in this fingerprint (unless someone
wants to challenge this assumption) - the guard discovery attack and bridge
enumeration are examples of this. Basically, pinning the middle hop(s) let
an adversary know that it is part of an onion service's circuit, even
potentially which one. If we assume that guards are the best way to mitigate
certain attacks on onion services, then using layered-guards now seems like
an important extension of that. Therefore, if the second hop is pinned, those
nodes may be able to determine that they are included in the vanguard set of
a high(er) security hidden service. As long as traffic analysis is useful, I
don't know if we can have 3.3 without having 3.2 (but please think about
design improvements).