Ola Bini obini@thoughtworks.com writes:

Hi,

...

I think it's fine to use randomness to generate it for now; that's what tor also currently does [0].

Cool - we have a local clone of the specs and updating it with this understanding.

Great!

For better or worse I think making design decisions (or at least simulating them) as well as improving and finalizing the spec is a big part of this task :)

...

The real lifetime of guards is currently a random value between 2 to 3 months (see chosen_on_date) This is regardless of whether the guard is your primary guard or not. We might increase the lifetime in the future, but probably the precise value should not matter too much since it's a constant change.

Does this mean the choice of guard is saved in the state file or config file?

Indeed. It is saved in the state file. Check the end of: https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html also see here for another explanation of how parts of it work: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html

Should the PRIMARY_GUARDS chosen by #259 here be saved as well?

Hmm. Not sure how this will work exactly in practice.

The way I imagine it, is that the first N_PRIMARY_GUARDS active guards on your guard list are considered to be your primary guards. It's more of a label, than a static set. That's because the set of primary guards changes over time, as nodes go inactive. Like prop259 says, "by 'active' we mean that we only consider guards that are present in the latest consensus as primary".

I suspect that might not work very well because of the difference between dystopic and utopic networks, and when people move around between networks. Or maybe we should have two sets, UTOPIC and DYSTOPIC PRIMARY_GUARDS that are more long lived?

Hmm... Not sure how this would work if utopic and dystopic guard lists are separated. That is if there should be both dystopic primary guards _and_ entropic primary guards.

I'd personally prefer the approach where we don't have such strictly separated guard lists. I tried to explain parts of it in the top of this email: https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html but it probably requires more design work.

The way I'm thinking of it, we have a main guardlist GUARDS, where we put every guard we have sampled and connected or planning to connect to. We would sample both normal and 80/443 guards for this guardlist. This guardlist should work for most clients (except from 80/443 firewalled clients).

To handle these 80/443 firewalled clients, if we try more than GUARDLIST_FAILOVER_THRESHOLD nodes from GUARDS and we can't connect, then we consider it to be a firewall issue, and go into "dystopic firewall mode". During this mode we only sample dystopic guards (potentially from a separate DYSTOPIC_GUARDS guardlist). If we try more than GUARDLIST_FAILOVER_THRESHOLD of guards from the dystopic guardlist, then we complain about network issues.

(There are various optimizations and heuristics that can be applied to the above system, but let's not get to them now.)

[The reason I don't like having separate disjoint utopic and dystopic guardlists and first trying the former and then the latter, is because it means that normal people will use the utopic guards, and the dystopic guards will only be used by people that have 80/443 firewalled. We don't really know how big these user sets are right now so it's hard to make load-balancing assumptions, and from a security PoV we should probably not isolate those user sets if we can help it.]

Bleh sorry for the mess... It's been a while since I've thought of this stuff.