[tor-bugs] #26294 [Core Tor/Tor]: attacker can force intro point rotation by ddos

[Tor Bug Tracker & Wiki]

#26294: attacker can force intro point rotation by ddos
-------------------------------------------------+-------------------------
 Reporter:  arma                                 |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tor-dos, network-team-       |  Actual Points:
  roadmap-2019-Q1Q2                              |
Parent ID:  #29999                               |         Points:  7
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by asn):

 Back when that ticket was filed, I also had the chance to meet with some
 onion service experts and independently discuss this issue. Here are some
 unpublished notes:

 We decided that allowing this attack because of the replay cache is a red
 herring. Specifically, the replay cache is not that big with only 16k-32k
 requests so we could indeed grow it.  Furthermore, we could also clear the
 cache after X requests and start with a new one; that would allow the
 attacker to replay each introduction once, but that's fine because making
 new intro requests is not *that heavy* anyway, and it's definitely better
 than allowing them to rotate our intro points non-stop.

 Also it's important to realize that the replay cache is held on the HS-
 side and not on the intropoint-side. I just verified this in our codebase,
 because I was also confused about this! The HS keeps two (!) replay caches
 for each INTRODUCE2 cell: one is per-intropoint (v3: replay_cache / v2:
 accepted_intro_rsa_parts) and the other is per-HS and (v3:
 replay_cache_rend_cookie / v2: accepted_intro_dh_parts).

 I think what we should do here is:

 a) Short-term: Reevaluate our replay detection strategy and see whether
 it's indeed too heavy. Evaluate whether we need both caches. Evalute the
 size of our replay caches given X requests. Evaluate whether we can clear
 our replay caches after Y requests and just keep on using the same intro
 points.

 c) Medium-term: Consider more high-level directions to handle big load,
 like proof of work, path selection, or other intro protocol.s

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26294#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online