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

[nickm]

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

[nickm]

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

We'll need a corresponding spec update.

[nickm]

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

[asn]

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.

[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 or its kin about how having 3 directory guards prevented #20499 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.

[teor]

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

[asn]

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 or its kin about how having 3 directory guards prevented #20499 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?

[nickm]

Squashed and rebased as ticket20831_v2.

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

[nickm]

Merged!