Opened 3 years ago

Last modified 5 months ago

#20832 assigned enhancement

Design proposals to further improve guard security

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-guard, TorCoreTeam201705, 034-triage-20180328, 034-removed-20180328
Cc: Actual Points:
Parent ID: #20822 Points: 2
Reviewer: Sponsor:

Description

I have a couple of proposal sketches that I would like to write for making the prop271 guard algorithm work even better. In particular, I would like to better resist the case where we start up for the first time with a hostile ISP that's determined to control our long-term guard choices.

Child Tickets

Change History (20)

comment:1 Changed 3 years ago by dgoulet

Keywords: tor-guard added

comment:2 Changed 3 years ago by nickm

Here are the ideas I have in my notes; they'll need some expansion to become proposals. And possibly to make any sense to anyone.

.....

The main problem this algorithm faces right now is the initial bootstrapping if the ISP is eeeevil. We're not doing worse than previously (I think), but we could do better. Some Ideas to improve this:

  • Mark the initial identity guards as "semi-confirmed" somehow so they can retain priority for a while in case the user breaks out.
  • Maintain a "suspicion index" for each guard: maybe, the number of guard that were down before it when it was confirmed?
  • Maybe, don't confirm guards when the primary guards are down if we're about to retry??? [didn't think about that one so much.]
  • Maybe when a circuit launches earlier than another , if both guards become confirmed, the one that was launched first should be confirmed with earlier confirmed_idx?

comment:3 Changed 3 years ago by nickm

Owner: set to nickm
Status: newassigned

comment:4 Changed 3 years ago by nickm

Points: 2

comment:5 Changed 3 years ago by nickm

Type: defectenhancement

batch modify: I think these are "enhancement", though I could be wrong about some.

comment:6 Changed 3 years ago by nickm

Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Deferring these to 0.3.1.x as nonbugfixes.

comment:7 Changed 3 years ago by nickm

Keywords: TorCoreTeam201703 added

comment:8 Changed 3 years ago by nickm

Sponsor: SponsorZ

comment:9 Changed 3 years ago by nickm

Keywords: TorCoreTeam201705 added
Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

These are things I should work on during May, but they're prep work for 0.3.2 and beyond.

comment:10 Changed 2 years ago by nickm

Keywords: TorCoreTeam201703 removed

comment:11 Changed 2 years ago by nickm

Sponsor: SponsorZSponsorV

comment:12 Changed 2 years ago by nickm

Sponsor: SponsorVSponsorV-can

comment:13 Changed 2 years ago by nickm

Milestone: Tor: 0.3.2.x-finalTor: 0.3.3.x-final

comment:14 Changed 22 months ago by dgoulet

Milestone: Tor: 0.3.3.x-finalTor: 0.3.4.x-final

comment:15 Changed 20 months ago by nickm

Keywords: 034-triage-20180328 added

comment:16 Changed 20 months ago by nickm

Keywords: 034-removed-20180328 added

Per our triage process, these tickets are pending removal from 0.3.4.

comment:17 Changed 20 months ago by nickm

Milestone: Tor: 0.3.4.x-finalTor: unspecified

These tickets, tagged with 034-removed-*, are no longer in-scope for 0.3.4. We can reconsider any of them, if time permits.

comment:18 Changed 6 months ago by gaba

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

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

comment:20 Changed 5 months ago by nickm

Owner: nickm deleted

These tickets are not things I'm currently working on. They may be important, but they don't need to be done by me specifically. Un-assigning.

Note: See TracTickets for help on using tickets.