-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi teor,
On 1/24/2016 12:11 AM, Tim Wilson-Brown - teor wrote:
Hi s7r,
Great proposal, I really like it - I think it targets the actual behaviour we want to prevent in a less complex manner than the HS 3rd-hop alternatives being discussed for prop247.
Thanks!
Some general questions:
- Do we want to make this behaviour (somewhat) symmetric, so that a
client which sees a hidden service choose the same introduction point(s) for N periods will refuse to use that introduction point?
I don't think so. I am not concerned about clients, given that they cannot be made to build circuits, only they initiate them. Plus the client builds normal circuit to the introduction points afaik, and we don't want to overload the client with more stuff to process. For the hidden service servers, it's totally worth the effort.
- This will break some Tor2Web installations, which deliberately
choose rendezvous points on the same server or network for latency reasons. (Forcing Tor2Web installations to choose multiple RPs may be a worthwhile security tradeoff.)
Yes, but there is a HiddenServiceRendFilter 0 in the proposal for this purpose and for RSOS services as well.
- Security implications for maintaining such records in the
persistent state of a hidden service server
An attacker which compromises the location of a hidden service server will access this additional information: total number of rendezvous circuits built within the last REND_FILTER_MONITOR_PERIOD and to which rendezvous points these circuits were. This tradeoff should be worth it as well, since if the location of a hidden service server is compromised it is game over anyway, and this additional information shouldn't be so important to the attacker, except maybe for better determining the popularity of that hidden service (this can be determined many other ways, like the logs from the application running behind the hidden service, network counter, datacenter/ISP level counters and logs, etc.).
To reduce the sensitivity of these counters, we should discard them after a certain period of time, perhaps every hidden service period (24 hours?)
We could also add noise and/or round into buckets, like we do for other statistics, but I'm not sure there's much point, as they are never seen outside the hidden service.
Hmm, we should think about this. The 24 hours will in fact be the latest 24 hours as of $now, something like this.