Nicholas Hopper hopper@cs.umn.edu wrote:
On Sun, Jul 12, 2015 at 4:48 PM, John Brooks john.brooks@dereferenced.net wrote:
Comments are encouraged, especially if there are downsides or side effects that we haven’t written about yet, or that you have a different opinion on. The intent is that we can decide to do this before implementing proposal 224, so they can be implemented together.
So an IP can do some things attack-wise that an HSDir cannot:
- Availability monitoring (useful for intersection or confirmation)
- Some side-channel linking attacks like latency and relay-clogging
- ... other things? I feel like there could be more…
Fair points. We need to think carefully about this, but at a glance it doesn’t concern me very much: both of these capabilities are also available to clients. If the IP+HSDir can identify the service (knows the unblinded public key), it could do the same attacks as a client. This may be more relevant for some client-authorized services.
This proposal also makes it more difficult to get your IP chosen for a target service, so it could be an improvement against this attacker.
This proposal doubles the default number of IPs and reduces the “cost" of being an IP since the probability of being selected is no longer bandwidth-weighted. Is this a fair tradeoff for the performance improvement?
Viewed from the other direction, this proposal keeps the cost and attacker probabilities of being HSDir the same, and eliminates the risks from selecting additional relays as introduction points. It’s a win against an adversary with a malicious relay.
I think it's a security improvement _and_ a performance improvement.
- John