Opened 2 years ago

Last modified 13 months ago

#20832 assigned enhancement

Design proposals to further improve guard security

Reported by: nickm Owned by: nickm
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: SponsorV-can

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 (17)

comment:1 Changed 2 years ago by dgoulet

Keywords: tor-guard added

comment:2 Changed 2 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 2 years ago by nickm

Owner: set to nickm
Status: newassigned

comment:4 Changed 2 years ago by nickm

Points: 2

comment:5 Changed 2 years ago by nickm

Type: defectenhancement

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

comment:6 Changed 2 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 2 years ago by nickm

Keywords: TorCoreTeam201703 added

comment:8 Changed 2 years ago by nickm

Sponsor: SponsorZ

comment:9 Changed 2 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 22 months ago by nickm

Sponsor: SponsorZSponsorV

comment:12 Changed 22 months ago by nickm

Sponsor: SponsorVSponsorV-can

comment:13 Changed 20 months ago by nickm

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

comment:14 Changed 15 months ago by dgoulet

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

comment:15 Changed 13 months ago by nickm

Keywords: 034-triage-20180328 added

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

Note: See TracTickets for help on using tickets.