[tor-dev] blacklisting relays with end-to-end correlation capabilities?
hahn.seb at web.de
Tue May 9 12:11:25 UTC 2017
below mail was meant to make it to tor-dev, but I got a bounce and didn't
notice until now. Whoops, my apologies.
> On 8. Dec 2016, at 14:29, Sebastian Hahn <tor at sebastianhahn.net> wrote:
>> On 08 Dec 2016, at 14:03, nusenu <nusenu at openmailbox.org> wrote:
>> Dear tor directory authorities,
>> TLDR: Would you blacklist relays with end-to-end correlation capabilities?
>> I'm asking to find out whether it makes sense to put any effort into
>> finding such operators . If most dir auths would not blacklist such
>> relays than it does not make sense to look for them I guess.
>> So please let us know whats your opinion on that - thank you.
>> More information below and there :
>> The process could look something like this:
>> - someone identifies such a relay groups (basically based on contactinfo
>> - contact the operators asking to fix this (ideally this would be a
>> @torproject.org sender)
>> - give them 15 days to fix it
>> - if not fixed: blacklist respective guard relays
>> - give them the possibility to get removed from the blacklist once fixed
> I do not think that this is worthwhile. It establishes a precedent where
> setting your contact info is something that gets you banned, potentially
> incorrectly because it's unauthenticated, whereas we're unable to identify
> people who actually maliciously run several relays without such indicators.
> Additionally, it's yet one more thing to update the dirauths' configs
> for, but with rather more overhead as we might get multiple mails back
> and forth about how MyFamily is annoying to maintain, how they're just
> trying to help, etc. All not so bad arguments.
> If we did this, also why would we blacklist the nonexit relays? That
> seems to not make sense, as a relay operator could have multiple relays
> that act as guard and exit simultaneously. I think we'd need to
> blacklist at least all the exit relays, if not all of them. BadExiting
> them would then be the more sensible choice. Scarcity of resources has
> in the past led us to bad designs like Valid/Invalid relays etc, which
> causes way more annoyances than good things.
More information about the tor-dev