[tor-dev] Guard node security: ways forward (An update from the dev meeting)

[George Kadianakis <desnacked@xxxxxxxxxx>]

A main theme in the recent Tor development meeting was guard node
security as discussed in Roger's blog post and in Tariq's et al. paper [0].

Over the course of the meeting we discussed various guard-related
subjects. Here are some of them:

a) Reducing the number of guards to 1 or 2 (#9273).

b) Increasing the guard rotation period (to 9 months or so) (#8240).

c) The fact that your set of guard nodes can act as a network
   fingerprint even if you switch to different networks (#10969).

d) The fact that authorities assign flags based on knowledge they
   acquired while they were up. They don't use historical data to
   assign flags, which means that an authority thas has been up for 1
   month, only knows 1 month worth of information about each relay
   (#10968).

e) We discussed introducing a weight parameter that makes guards that
   have been guards for a long time, be more likely to be used as
   guards.

f) We discussed how guards and circuit isolation should work
   together. Maybe each isolation profile should have a different set
   of guards. But what if we have hundreds of isolation profiles (we
   are the gateway of a network)?

g) Should we refuse to add new guards after a certain number of
   circuits have been killed (maybe it's an attack). But won't that
   drive our users to simply reinstall Tor because they think it's
   broken?

h) We discussed chaining consensus documents together as in a block
   chain. This could help against targetted attacks where a set of bad
   authorities give a poisoned consensus to a user. This design has
   many problems though (how much data do we have to keep forever each
   consensus? what happens in periods where no consensuses were
   published?)

i) If we restrict the number of guards to 1, what happens to the
   unlucky users that pick a slow guard? What's the probability of
   being an unlucky user? Should we bump up the bandwidth threshold
   for being a guard node? How does that change the diversity of our
   guard selection process?

j) How do the above influence the security of Hidden Services?  Guard
   security is essential for the well-being of Hidden Services, but
   how does increasing the guard rotation period combine with guard
   enumeration attacks (#9001)?

We discussed more topics too. You can find Nick's raw notes at:
https://trac.torproject.org/projects/tor/wiki/org/meetings/2014WinterDevMeeting/notes/GuardDesign

To move forward, we decided that proposals should be written for (a)
and (b). We also decided that we should first evaluate whether doing
(a) and (b) are good ideas at all, especially with regards to (i).

[0]: https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
     http://freehaven.net/anonbib/#wpes12-cogs
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev