Support existing guard torrc options better with new guard code, or deprecate them.

These torrc options are guard-related, but I don't know how well the new code supports them (or in some cases, I rather suspect it doesn't).

* UseEntryGuards
* UseEntryGuardsAsDirGuards. (I vote, deprecate this.)
* NumEntryGuards
* NumDirectoryGuards. (I vote, deprecate this.)
* GuardLifetime

changed milestone to %Tor: 0.3.0.x-final

added TorCoreTeam201612 actualpoints::.2 component::core tor/tor milestone::Tor: 0.3.0.x-final owner::nickm parent::20822 points::2 priority::high regression resolution::fixed severity::normal status::closed tor-guard type::defect labels

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

Trac:
Priority: Medium to High
Keywords: tor-guard deleted, tor-guard regression added
Status: new to accepted
Owner: N/A to nickm

Trac:
Keywords: tor-guard regression deleted, tor-guard regression TorCoreTeam201612 added
Points: N/A to 2

My ticket20831 branch, on top of prop271_030_v1, handles these cases.

We'll need a corresponding spec update.

Trac:
Status: accepted to needs_review
Actualpoints: N/A to .2

I've modified ticket20831 to reinstate NumDirectoryGuards, since multiple directory guards is actually a pretty good idea (see ticket #20950 (moved)).

Patch looks plausible, but I'm not entirely sold yet.

I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much security, if the top primary guard is malicious. I remember the argument about malicious directory guards refusing to serve relay descriptors, but I kinda feel that we are screwed anyway if the top primary guard is evil since all circuits are going to go through it anyhow.

Also, the patch only supports multiple entry guards when it comes to primary guards, and does not try to generalize the logic to the other guard picking cases. A spec patch is definitely useful for this.

I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much security, if the top primary guard is malicious. I remember the argument about malicious directory guards refusing to serve relay descriptors, but I kinda feel that we are screwed anyway if the top primary guard is evil since all circuits are going to go through it anyhow.

Right. My rationale here was more strongly influenced by one of the comments on #20909 (moved) or its kin about how having 3 directory guards prevented #20499 (moved) from causing major chaos on the network.

Also, the patch only supports multiple entry guards when it comes to primary guards, and does not try to generalize the logic to the other guard picking cases.

The choice that multiple entry guards only applies to primary guards was intentional, since if we're ever prevented from using all our primary guards, we want to be cautious about using more guards.

A spec patch is definitely useful for this.

Can do, once we decide we should do something like this.

I agree, it's important to have more than one directory guard for performance and reliability reasons. Security is secondary here.

Replying to nickm:

I'm not 100% persuaded that NumDirectoryGuards==3 actually offers much security, if the top primary guard is malicious. I remember the argument about malicious directory guards refusing to serve relay descriptors, but I kinda feel that we are screwed anyway if the top primary guard is evil since all circuits are going to go through it anyhow.

Right. My rationale here was more strongly influenced by one of the comments on #20909 (moved) or its kin about how having 3 directory guards prevented #20499 (moved) from causing major chaos on the network.

Hmm, interesting. In this case wouldn't it be ideal if Tor consulted the second primary guard, if and only if the first primary guard delivered expired/corrupted information? Instead of always picking at random between the top 3 guards?

Because with the current patch we end up exposing ourselves to 3 primary guards anyhow even if the first primary guard is totally innocent.

Are we afraid that implementing the above logic would be too much engineering time?

Squashed and rebased as ticket20831_v2.

I'm opening #21006 (moved) about reducing NumDirectory guards, and merging this to master.

Merged!

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

closed

changed time estimate to 16h

added 1h 36m of time spent

mentioned in issue #21006 (moved)

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

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