Michael Rogers michael@briarproject.org writes:
On 10/05/14 21:09, George Kadianakis wrote:
It's interesting that you say this, because we pretty much took the opposite approach with guard nodes. That is, the plan is to extend their rotation period to 9 months (from the current 2-3 months). See: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-gu...
I was even planning on writing an extension to rend-spec-ng.txt to specify how IPs should be picked and to extend their rotation period. That's for the same reason we do it for entry guards:
Hi George,
Is there an analysis somewhere of why it would be better to change IPs less frequently?
No, this analysis hasn't been done yet. I'd have to do the analysis before writing the patch to rend-spec-ng.txt and that's why I haven't written it yet.
It's still unclear to me whether keeping IPs for longer periods of time is a good idea; I suggested it as a possible approach because we recently took a similar decision for guard nodes (see my previous mail). More analysis must be done.
Also, note, that if the scaling ideas get implemented, the IPs become more important in the HS threat model. For example, many of the suggested scaling schemes allow the IPs to learn the number of HS nodes, or to decide which HS node should receive a given connection.
I think it would be good for the performance of mobile hidden services, but I'm concerned about the attack waldo described eariler in this thread, in which a malicious IP breaks circuits until the service builds a circuit through a malicious middle node, allowing the attacker to discover the service's entry guard.
I couldn't find the attack you described in this thread. This thread is quite big.
However, I'm not sure how rotating IPs _more frequently_ can help against the guard discovery attack you described. It would seem to me that the contrary is true (the fewer IPs you go through, the less probability you have for one of them to be adversarial).
Perhaps the attack could be mitigated by keeping the same middle node and IP for as long as possible, then choosing a new middle node *and* a new IP when either of them became unavailable? Then a malicious IP that broke a circuit would push the circuit onto a new IP.
Also see https://lists.torproject.org/pipermail/tor-dev/2013-October/005621.html .
Unfortunately, it seems to me that the 'virtual circuit' idea is messier than we imagine, and taking the 'guard layers' approach might be less dangerous and easier to analyze.