Opened 20 months ago
Last modified 6 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:
- Do nothing. (If we choose this, I want us to do it for specific reasons, rather than default to it).
- Use two guards, and ensure one is from a different /16 and node family (Section 1.1 and 1.2).
- Abandon all of Tor's path restrictions (Section 3.1)
- 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 20 months ago by
Keywords: | tor-guard guard-discovery added |
---|
comment:3 Changed 20 months ago by
Replying to mikeperry:
At a high level, the choices are:
- Do nothing. (If we choose this, I want us to do it for specific reasons, rather than default to it).
- Use two guards, and ensure one is from a different /16 and node family (Section 1.1 and 1.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.
comment:4 Changed 19 months ago by
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 17 months ago by
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 6 months ago by
Removing sponsor V as we do not have more time to include this tickets in the sponsor.
comment:7 Changed 6 months ago by
Sponsor: | SponsorV-can |
---|
Removing sponsor from tickets that we do not have time to fit in the remain of this sponsorship.
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?