Make Prop#291 ("Move to two guard nodes") choices

We should make some decisions about Proposal 291, since what we expect to do there influences how we want to handle vanguards and other things.

The torspec.git proposal text is currently exactly the same as "Proposal: The move to two guard nodes" on the tor-dev mailinglist, in case people want to reply point-by-point.

In particular, I wrote Section 3 with arma and Nick's points in mind, and section 2.4 with Isis's points in mind.

At a high level, the choices are: 0. Do nothing. (If we choose this, I want us to do it for specific reasons, rather than default to it).

1. Use two guards, and ensure one is from a different /16 and node family (Section 1.1 and 1.2).
2. Abandon all of Tor's path restrictions (Section 3.1)
3. Don't use Guard nodes as exits, RPs, HSDirs, or IPs. (Section 3.2)

Tickets that are affected by our choice here include legacy/trac#25753 (moved), legacy/trac#24487 (moved), and legacy/trac#25705 (moved).

changed milestone to %Tor: unspecified in legacy/trac

moved from tor#25754 (moved)

added 034-deferred-20180602 in Legacy / Trac 034-roadmap-subtask in Legacy / Trac 035-removed-20180711 in Legacy / Trac component::core tor/tor in Legacy / Trac guard-discovery in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac parent::25546 in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac status::new in Legacy / Trac tor-guard in Legacy / Trac type::defect in Legacy / Trac labels

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

Hello Mike,

I did a big analysis of the engineering side of prop#291 here: https://lists.torproject.org/pipermail/tor-dev/2018-April/013057.html

tl;dr Proposal will work well as currently written, but it can have some side-effects we might want to think more about (e.g. see legacy/trac#25783 (moved))

Also, do legacy/trac#24487 (moved) and legacy/trac#25705 (moved) actually depend on the decision we take here? Aren't they both good features to have in general?

Replying to mikeperry:

At a high level, the choices are: 0. Do nothing. (If we choose this, I want us to do it for specific reasons, rather than default to it).

1. Use two guards, and ensure one is from a different /16 and node family (Section 1.1 and 1.2).
2. Abandon all of Tor's path restrictions (Section 3.1)

This "all of Tor's path restrictions" phrasing is scary. First of all, we only need to relax the path restrictions on HS-related circuits right (particularly HSDir, IP and RP circs)? And in particular we need to relax the single restriction of disallowing guard and final hop being the same node (or in the same family or /16). No other path restrictions should be edited IIUC.

Deferring non-must tickets to 0.3.5

Trac:
Milestone: Tor: 0.3.4.x-final to Tor: 0.3.5.x-final
Keywords: N/A deleted, 034-deferred-20180602 added

These tickets are being triaged out of 0.3.5. The ones marked "035-roadmap-proposed" may return.

Trac:
Milestone: Tor: 0.3.5.x-final to Tor: unspecified
Keywords: N/A deleted, 035-removed-20180711 added

Removing sponsor V as we do not have more time to include this tickets in the sponsor.

Removing sponsor from tickets that we do not have time to fit in the remain of this sponsorship.

Trac:
Sponsor: SponsorV-can to N/A

mentioned in issue legacy/trac#29174 (moved)

moved from legacy/trac#25754 (moved)

added Bug label and removed 1 deleted label

added Deferred in Tor Guards in Tor labels and removed 1 deleted label

added Proposal Ideas label

removed Bug label

removed milestone

changed title from Make Prop#291 choices to Make Prop#291 ("Move to two guard nodes") choices

mentioned in issue tor#40363 (closed)

added Triage2022 in Tor label

added Icebox label