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 <[email protected]> wrote: > > 8. 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
