Opened 19 months ago

Last modified 6 months ago

#19162 accepted defect

Make it even harder to become HSDir

Reported by: asn Owned by: arma
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: 0.2.7
Severity: Normal Keywords: tor-hs tor-dirauth prop224 security needs-design
Cc: dgoulet, special, teor, nickm Actual Points:
Parent ID: Points: 4
Reviewer: Sponsor: SponsorR-can

Description

In #8243 we started requiring Stable flag for becoming HSDirs, but this is still not hard enough for motivated adversaries. Hence we need to make it even harder for a relay to become HSDir, so that only relays that have been around for long get the flag. After prop224 gets deployed, there will be less incentive for adversaries to become HSDirs since they won't be able to harvest onion addresses.

Until then, our current plan is to increase the bandwidth and uptime required to become an HSDir to something almost unreasonable. For example requiring an uptime of over 6 months, or maybe requiring that the relay is in the top 1/4th of uptimes on the network.

Child Tickets

Attachments (1)

moria1-cutoffs (96.3 KB) - added by arma 19 months ago.
vote thresholds from moria1 running task19162-interim

Download all attachments as: .zip

Change History (20)

comment:1 Changed 19 months ago by arma

Keywords: TorCoreTeam201606 added; SponsorR removed
Owner: set to arma
Status: newaccepted

comment:2 Changed 19 months ago by asn

Keywords: SponsorR 029-proposed added; TorCoreTeam201606 removed
Milestone: Tor: 0.2.9.x-finalTor: unspecified

comment:3 Changed 19 months ago by arma

Keywords: TorCoreTeam201606 added

comment:4 Changed 19 months ago by arma

See my task19162-interim branch for the code I've been running on moria1 so far (not ready for merge).

It adds two new requirements for the HSDir flag:

  • A minimum bandwidth weight. I tried a variety, and right now it's requiring that the relay be in the top 75% of active relays by weight. On moria1 right now that's a weight of 111. (For comparison, the top 7/8's cutoff for Fast is 102.)
  • A minimum relative time-known. I tried a variety, and right now it's requiring that the relay be in the top 25% of active relays by time-known. On moria1 right now that's 5669438 seconds aka 65 days.

Changed 19 months ago by arma

Attachment: moria1-cutoffs added

vote thresholds from moria1 running task19162-interim

comment:5 Changed 19 months ago by arma

Now here's the mystery. I attached moria1's vote cutoffs from each hour over the past while. The tk threshold goes up by roughly an hour, every hour. It never goes down. How could this be? Shouldn't it be going up and down, depending on which relays are 'active' at the time?

comment:6 Changed 18 months ago by arma

asn asked if the mystery is solved. I think we're still where we were 12 days ago.

comment:7 Changed 18 months ago by nickm

Cc: nickm added
Milestone: Tor: unspecifiedTor: 0.2.9.x-final

comment:8 Changed 18 months ago by nickm

17:20 < nickm> dgoulet, armadev : on #19162 ,is the help you want "try to 
               figure out why the 'mystery' is happening?" or something else
17:22 < dgoulet> nickm: well yes, why this uptime value is always growing and 
                 never "fluctiating" like it should is what we are trying to 
                 understand
17:22 < armadev> yes, correct. it is totally possible that the time-known thing 
                 is actually broken and has been this whole time. anything is 
                 on the table.

comment:9 Changed 18 months ago by asn

Hmm, interesting. I tried to repro this in chutney, and indeed the tks seem to increase all the time even if I kill some of the relays. However, I don't know if rephist works the same in chutney as in the normal net, so this might be worth exploring further on moria.

Roger, how would you feel about adding something like this:

  {
    int i = 0;
    for (i = 0 ; i < n_active; i++) {
      log_warn(LD_GENERAL, "TK %d/%d: %ld", i, n_active, tks[i]);
    }
  }

in dirserv_compute_performance_thresholds() after the tks array gets initialized? That will result in about 6k lines of logs every hour... But just doing it for a few hours should be sufficient to get some understanding.

When I did the above in chutney, all the tk elements seem to increase even if the corresponding relay was down. Also, the first element of the array was always set to 0 (maybe that's us and it's a bug?).

(Finally, looking at moria's logs, guard_tk seems to always be set to TIME_KNOWN_TO_GUARANTEE_FAMILIAR. I guess that's on purpose.)

comment:10 Changed 18 months ago by nickm

Points: 4

comment:11 in reply to:  9 Changed 17 months ago by arma

Replying to asn:

Roger, how would you feel about adding something like this:

  {
    int i = 0;
    for (i = 0 ; i < n_active; i++) {
      log_warn(LD_GENERAL, "TK %d/%d: %ld", i, n_active, tks[i]);
    }
  }

in dirserv_compute_performance_thresholds() after the tks array gets initialized?

I have run that patch on moria1 for a while. The TK lines are in
http://freehaven.net/~arma/19162-tk-data.bz2 (6.7MB compressed so too big to attach here).

comment:12 Changed 16 months ago by asn

Keywords: TorCoreTeam201608 added; TorCoreTeam201606 removed

comment:13 Changed 16 months ago by asn

Roger is it still the case that the tk cutoffs in your logs are strictly increasing?
Can you post some more recent "Cutoffs" logs to verify this?

If that's still the case, the next move here is to take the tk dataset that you posted a month ago, and make a python script that calculates the cutoffs, and test if they are also strictly increasing. Unfortunately, we don't have the corresponding "Cutoffs" logs for those dates, to check the correctness of the script.

comment:14 Changed 15 months ago by nickm

Keywords: 029-proposed removed

That which is already in 0.2.9 cannot be 029-proposed.

comment:15 Changed 15 months ago by nickm

Keywords: nickm-deferred-20161005 added
Milestone: Tor: 0.2.9.x-finalTor: 0.3.0.x-final

Deferring big/risky-feature things (even the ones I really love!) to 0.3.0. Please argue if I'm wrong.

comment:16 Changed 12 months ago by dgoulet

Cc: special added; special. removed
Keywords: SponsorR TorCoreTeam201608 nickm-deferred-20161005 removed

comment:17 Changed 12 months ago by dgoulet

Keywords: triage-out-030-201612 added
Milestone: Tor: 0.3.0.x-finalTor: unspecified

Triaged out on December 2016 from 030 to Unspecified.

comment:18 Changed 7 months ago by nickm

Keywords: triage-out-030-201612 removed

comment:19 Changed 6 months ago by nickm

Keywords: tor-dirauth prop224 security needs-design added
Note: See TracTickets for help on using tickets.