[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:  asn
     Type:  defect                               |         Status:
                                                 |  merge_ready
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  0.4.2.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs, tor-dos, network-team-       |  Actual Points:  6
  roadmap-august, security                       |
Parent ID:  #29999                               |         Points:  7
 Reviewer:  dgoulet                              |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------

Comment (by nickm):

 I think I have to ''lean'' "no" on this for 0.4.2 right now; it removes
 one security feature to add another, and I am worried about the
 implications.  I'm also worried about increasing the memory load for
 services so much: it seems prohibitive for a service that is running on
 (say) a cheap android device, yeah?

 On the alternatives:
   * Bloom filters have an accuracy/storage tradeoff, so if we use one, we
 still need to be prepared to either get false positives, or replace the
 filter periodically.  It's still more space-efficient than the hash map
 though.
   * Timestamps are really scary to me; they leak information about the
 client's view of the time, which can be correlated to the time it sends in
 other places.

 Here in another alternative that we could do:
    * Allow replay caches to grow without bounds; when we approach
 MaxMemInQueues, evict a random subset of the cache and/or close the
 circuit.

 For 0.4.2, I'd be fine with increasing the limit of cells per introduction
 circuit, and doing a better solution for 0.4.3.

 Roger suggests on IRC that this is complicated enough that we should write
 something up describing the goals, tradeoffs, and design rationale.  That
 sounds like a proposal to me. :/

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