Nicholas Hopper <[email protected]> wrote: > On Sun, Jul 12, 2015 at 4:48 PM, John Brooks > <[email protected]> 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
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
