Opened 16 months ago

Last modified 7 weeks 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 16 months ago by catalyst

Keywords: tor-guard guard-discovery added

comment:2 Changed 16 months 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 15 months ago by asn (previous) (diff)

comment:3 in reply to:  description Changed 15 months 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 14 months 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 12 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 7 weeks ago by gaba

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

comment:7 Changed 7 weeks 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.