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.
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?
* 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.)
On 24 Jan 2016, at 08:38, s7r s7r@sky-ip.org wrote:
- 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.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F