Ola Bini obini@thoughtworks.com writes:
p> several consensuses.
Yes, that's also my understanding.
I think what prop259 tries to do with that hashring construction is to provide a deterministic way to sample guards, with minimum shifting as time passes. The aim here is to make it harder to track and fingerprint clients based on their guard lists. The idea is that when you are in WiFi "home" you always have one set of guards, and when you move to the WiFi "cafe" you have a different set of guards. See #10969 for some background and check http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-19-16.03.log.html starting from 16:21:58 for some recent discussion.
Personally, I think that the hashring is kind of a red herring in the sense that it makes prop259 more complex than it needs to be, and it also tries to tackle a problem that we don't really know how to solve. I mean even if we have the hashring construction, how do we use it? Do we just blend in the MAC of the network gateway when we sample guards? What happens if an evil gateway changes its MAC constantly, till we sample the guards it wants?
I think solving the guard fingerprinting issue should be the subject of a separate proposal. Isis suggested this during the meeting but I was too dump at that point.
Until we have a proper solution here I'd suggest we stick to the KISS thing, which probably is to sample guards from a simple list weighted by their bandwidth like Tor is currently doing (see node_sl_choose_by_bandwidth()).
Of course, if you guys are interested in this and want to simulate the hashring idea (or any othe similar idea) that's fine as well. That's the good part of a simulation; that we don't need to commit to any particular construction.
I think prop259 suggests that we populate the guardlists the first time Tor attempts to connect to a network. This is different to how Tor currently does it, where it starts with a minimal guardlist (one guard), and adds new guards to it on demand (when the first guard fails).
Both approaches have their merits. I'm not sure which one is better.
We add more guards to guardlists if all the previous guards don't work anymore. This can be seen in step 4 of §2.
We also need to mark (update) guards as unreachable when they get removed from the consensus, or when we fail to connect to them.
Indeed the proposal should be updated to better specify when these actions happen and how they work.