[tor-dev] blacklisting relays with end-to-end correlation capabilities?

[nusenu]

Sebastian Hahn wrote (2016-12-08):
>> 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 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.

I understand dir auth operators have limited resources, but if you (most
of the dir auths) agree that blacklisting specific relays to protect tor
end users makes sense:

Would you agree on handling a limited amount (6?) of such 'end-to-end'
cases per year?

I.e. one case every 2 months if the operator has a guard probability
>0.1% and exit_probability >0.1% and didn't fix the problem within a
month after getting contacted?

Note: Luckily the list of such known potential operators is currently
very short (<5).

In the past month I had some positive effect when trying to contact
relay operators [1], but unfortunately the biggest operators (by
consensus weight) are not to motivated to fix their configuration in a
reasonable time frame.

thanks,
nusenu





[1]
https://lists.torproject.org/pipermail/tor-relays/2016-December/011520.html
https://lists.torproject.org/pipermail/tor-relays/2016-December/011507.html
https://lists.torproject.org/pipermail/tor-relays/2016-December/011476.html
https://lists.torproject.org/pipermail/tor-relays/2016-December/011486.html
https://lists.torproject.org/pipermail/tor-relays/2016-December/011521.html
https://lists.torproject.org/pipermail/tor-relays/2016-December/011426.html


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170103/8cf8f375/attachment.sig>