[tor-dev] Revisiting Proposal 246: Merging Hidden Service Directories and Introduction Points

[Michael Rogers]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x9FC527CC.asc
Type: application/pgp-keys
Size: 1731 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160114/b21ca011/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160114/b21ca011/attachment-0001.sig>