[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #2681 [Tor]: brainstorm ways to let Tor clients use yesterday's consensus more safely
#2681: brainstorm ways to let Tor clients use yesterday's consensus more safely
--------------------------------------------------------------------------------+
Reporter: arma | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Tor: 0.2.4.x-final
Component: Tor | Version:
Keywords: dirauth-dos-resistance proposal-needed MikePerry201210d tor-client | Parent: #2664
Points: | Actualpoints:
--------------------------------------------------------------------------------+
Comment(by arma):
Initial thoughts:
- s/Implementation Nodes/Implementation Notes/
- It's good we're not trying to do this back in the era of normal
descriptors. We throw those out after 24 hours, and we've had some concern
in the past that it would be harder to move to a "after 24 hours but not
if they're still referenced in a consensus" model.
- While thinking about this I pondered trying to draw a distinction
between "when I asked for a consensus they gave me this old one" and "I
haven't been able to fetch a consensus for the past two days, but I still
have this old one". The hope was that the former situation is scary
("under attack") but the latter is less scary ("undirected network
problems"). But since clients fetch dir stuff via begin_dir these days, I
don't think that distinction makes sense -- we can compare the time the
relay says it is with the time on the consensus. But if they're much
different, what do we do? "Log the possible attack and use it" is not so
good.
I miss a discussion of the risk from using a 4-day-old consensus. Right
now an adversary can give you his choice of 18 or so consensus documents,
and you'll try a couple times to get something better, while using the one
you've got. Now he can give you his favorite out of something like 120
consensuses. How much variance is there in them, and what are the
characteristics between them that make them 'more vulnerable to attack' or
less?
We should also make sure clients are asking with the "only give me a
consensus if the one you have is newer than this time" option, to save
bandwidth all around. (Alas, that's another leak about old client state --
"I'm the client that got its last consensus 36 days ago".)
Overall, I like the idea of bumping up the disaster timeframe. 5 days
seems as good as any other choice. I think since some of the logic we're
touching is finnicky, it'll be smartest to do some testing -- e.g. trigger
the conditions in a test network and see what actually happens.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2681#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs