Opened 2 years ago

Last modified 12 months ago

#25754 new defect

Make Prop#291 choices

Reported by: mikeperry Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: 034-roadmap-subtask, tor-guard, guard-discovery, 034-deferred-20180602, 035-removed-20180711
Cc: arma, isis, asn, nickm Actual Points:
Parent ID: #25546 Points:
Reviewer: Sponsor:

Description

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:

  1. Do nothing. (If we choose this, I want us to do it for specific reasons, rather than default to it).
  2. Use two guards, and ensure one is from a different /16 and node family (Section 1.1 and 1.2).
  3. Abandon all of Tor's path restrictions (Section 3.1)
  4. Don't use Guard nodes as exits, RPs, HSDirs, or IPs. (Section 3.2)

Tickets that are affected by our choice here include #25753, #24487, and #25705.

Child Tickets

Change History (7)

comment:1 Changed 2 years ago by catalyst

Keywords: tor-guard guard-discovery added

comment:2 Changed 2 years ago by asn

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 #25783)

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

Last edited 2 years ago by asn (previous) (diff)

comment:3 in reply to:  description Changed 2 years ago by asn

Replying to mikeperry:

At a high level, the choices are:

  1. Do nothing. (If we choose this, I want us to do it for specific reasons, rather than default to it).
  2. Use two guards, and ensure one is from a different /16 and node family (Section 1.1 and 1.2).
  3. 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.

comment:4 Changed 2 years ago by nickm

Keywords: 034-deferred-20180602 added
Milestone: Tor: 0.3.4.x-final → Tor: 0.3.5.x-final

Deferring non-must tickets to 0.3.5

comment:5 Changed 23 months ago by nickm

Keywords: 035-removed-20180711 added
Milestone: Tor: 0.3.5.x-final → Tor: unspecified

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

comment:6 Changed 12 months ago by gaba

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

comment:7 Changed 12 months ago by gaba

Sponsor: SponsorV-can

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

Note: See TracTickets for help on using tickets.