Implement directory guards

changed milestone to %Tor: 0.2.4.x-final

added component::core tor/tor dir-guards milestone::Tor: 0.2.4.x-final priority::medium prop207 resolution::implemented status::closed tor-client type::defect labels

Trac:
Keywords: N/A deleted, tor-client added

Trac:
Component: Tor Client to Tor

There's now a proposal 207 for directory guards.

Having it configured via a UseEntryGuardsAsDirectoryGuards option would be a perfectly fine idea.

I'm not sure whether this is a "big" or "small" feature right now; I'd like to try to get it in for the 10 Dec deadline either way.

Trac:
Summary: Add UseEntryGuardsAsDirectoryGuards option to Implement directory guards
Keywords: tor-client deleted, tor-client prop207 dir-guards added

Please review branch directory_guards in my public repository. It's based on fallback_dirsource_v3 for #572 (moved)

Trac:
Status: new to needs_review

This all looks fine to me.

s/gurads/guards/

Keeping a separate list of dir guards and entry guards means doubling the tls load on the network. It would be good to have some more understanding of what attacks we worry about when we use the some nodes for both lists -- because bridge users do that right now.

"UseEntryGuardsAsDirGuards" sounds like it means to use your entry guards as your directory guards. If that is indeed what it means, then the proposal no longer describes what is implemented. If it isn't what it means, it probably needs a clearer name.

Replying to arma:

s/gurads/guards/

Keeping a separate list of dir guards and entry guards means doubling the tls load on the network. It would be good to have some more understanding of what attacks we worry about when we use the some nodes for both lists -- because bridge users do that right now.

It doesn't keep a separate list.

"UseEntryGuardsAsDirGuards" sounds like it means to use your entry guards as your directory guards. If that is indeed what it means, then the proposal no longer describes what is implemented. If it isn't what it means, it probably needs a clearer name.

Right; see the discussion on tor-dev with mike from back when the proposal came out.

In addition to my comments on tor-dev, there's another reason to use the same list for each: client fingerprintability. If we keep two separate lists, your combined set of Guards+DirectoryGuards is absolutely fingerprintable as you move your tor client from IP to IP.

For some back of the envelope calculations, the current Guard entropy is ~9 bits. This is equivalent to 512 equal-sized guard choices. If we scale back to 2 guards, we have: https://www.wolframalpha.com/input/?i=512+choose+2

However, if we use 3 directory guards + 2 guards: https://www.wolframalpha.com/input/?i=512+choose+5

Neither are great, but the 2-guard case already doesn't segment our userbase, and will certainly experience enough change to damage the fingerprint as Guards go up and down while clients are offline/inactive. It seems unlikely that such rotation will make a significant impact on the 5-guard case's tremendous fingerprintability, though.

FWIW, the code does use the same list for both.

There is a weird log_notice in add_an_entry_guard that logs OH I SAY!. I'm not exactly sure what it's supposed to mean or say but it was probably forgotten there.

(Switching this to needs_revision.)

Trac:
Status: needs_review to needs_revision

(There are also some forgotten DOCDOCs.)

Thanks, asn! Those should be fixed now.

Trac:
Status: needs_revision to needs_review

Boże Narodzenie. This is merged to master.

Trac:
Resolution: N/A to implemented
Status: needs_review to closed

closed

mentioned in issue #7757 (moved)

moved to tpo/core/tor#6526 (closed)

mentioned in issue tpo/core/tor#7757 (closed)