On 13/01/16 20:42, s7r wrote:
After prop 250, a malicious HSDir can not do so much, but a merged HSDir + IP can for example kill the circuit and force the hidden service to rebuild it. Under the current design, we retry for some times and give up if an introduction point is unreliable, but with 246 we have to retry much more. If the same attacker also holds a reasonable % of middle bandwidth fraction in the Tor network, it will at least perform a successful guard discovery over the hidden service which is terrible. This may be fixed by not retrying a HSDir+IP too many times as described in section 4.3 of the proposal, but it will automatically lead to a capacity decrease (we have 5 HSDir + IP left out of 6).
The countermeasures in section 4.3 could be problematic for mobile hidden services, which have unreliable internet connections and therefore lose their intro circuits frequently. A service that lost its internet connection more than INTRO_RETRIES times in a consensus period would be left with no introduction points.
The discussions on guard selection have suggested that clients can't easily distinguish between relay failures and internet connection failures. On Android the OS broadcasts connectivity events that could be used to reset the retry counter via the control port, but I don't know about other platforms.
Cheers, Michael