On Tue 11 Feb 2014 01:53:54 PM EST, George Kadianakis wrote:
Qingping Hou dave2008713@gmail.com writes:
Hazards
a) How to design the scheme for mapping a random number to the same node between client and server?
This will be trivia if it's easy to synchronize node list between two onion proxy. The problem is: how much overhead will be caused by synchronizing node list (or consensus).Yes, this seems like a central problem to this proposal. Both parties will probably have to negotiate their consensus version in the beginning of the protocol to avoid ambiguities later on (since an attacker can choose between multiple valid consensus versions that might be convenient for him).
On Tue 11 Feb 2014 04:51:25 PM EST, Roger Dingledine wrote:
This one will indeed be tricky, since each side can have one of several "currently valid" views of the network (i.e. consensus networkstatus documents).
OK, as I mentioned in previous mail, one possible solution is to let two parties exchange consensus version and used the latest one. This approach is simple to implement and can encourage OPs to update their network view more frequently.
I just came up with another possible solution for this problem, which is based on the selection of responsible HSDirs.
Tor clients will only consider a consensus is valid if it's not older than 1 day. We can explore the fact that normally in a small period of time, Tor network should not change drastically. So different valid consensuses should share a large amount of nodes. The RP choose scheme works as follow:
1. two parties negotiate a random number R as noted in the proposal 2. put nodes into a circular list and order them based on identity digest (FP) (this is already implemented in Tor) 3. calculate hash of random number H(R) 4. find the the relay with identity digest cloesest to H(R)
This should work with pretty high probability as long as two parties' current consensus shares a large portion of relays.
Now what if they end up picking different RPs? This is easy: in the last step of random number negotiation, Client can send the relay she picked together with the R_a. Then HS can check whether they end up with the same one, if not, a request for renegotiation can be sent along the circuit.
Noted that current rendezvous circuit design also has similar problem. For example, the client might have a newer consensus and choose a RP that's not in HS's old consensus. In that case, HS will just give up without notifying the Client. My second proposed approach even solves this problem :)
Again, this still cannot prevent the abort-if-i-don't-like attack, but it's not a new vuln for HS anyway.
-- qp