Nicholas Hopper <hopper@xxxxxxxxxx> wrote: > On Sun, Jul 12, 2015 at 4:48 PM, John Brooks > <john.brooks@xxxxxxxxxxxxxxxx> 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
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev