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).