While I fully support the direction here I do wonder if there’s not also other information that could be used. Eg in bitcoin-land we have persistent issues with anti-privacy services operating large numbers of relays all one three ASNs. In the future, we’ll likely be shipping a compressed netblock -> primary ASN (where we map stub ASNs that always transit one upstream to their upstream) table with the software to limit connections to the same networks. Last I heard, Tor’s sybil attackers did something similar, so at least forcing them to establish business relationships with many hosting providers by limiting percentage of relays in a given ASN may be somewhat limiting. If nothing else, it also captures another useful trait that you don’t want to just bounce your traffic across five hosts in different OVH datacenters from a traffic correlation perspective.
Matt
On Jul 5, 2020, at 13:51, nusenu nusenu-lists@riseup.net wrote:
Thanks for all the positive off-list feedback so far!
a) require a verified email address for the exit or guard relay flag. (automated verification, many relays)
Wouldn't that be a hurdle for a lot of relay operators? I can imagine that many operators (of smaller relays) don't publish contact information for privacy reasons.
I believe you can have a valid ContactInfo and privacy.
Of course, in your proposal that information would only be shared with the directory authorities
That is not necessarily the case if the ContactInfo field is used without encryption, basically it is not specified yet.
but do we have any numbers on how many relay operators are okay with this?
I can only give you numbers based on the current tor network data (but that is not an answer to your question since it does not reveal anything about the operator's intention)
~71% of tor's guard capacity has a non-empty ContactInfo. About 700 guard relays have no ContactInfo set and are older than 1 month.
~89% of tor's exit capacity has a non-empty ContactInfo. Only about 60 exit relays have no ContactInfo set and are older than 1 month.
b) require a verified physical address for large operators (>=0.5% exit or guard probability) (manual verification, low number of operators). It is not required that the address is public or stored after it got verified. For details see bellow [2].
However, 0.5% seems like an arbitrary number to me. Can you provide some background information on how you got to this percentage? Is there maybe some way to calculate a malicious relay operator's deanonymisation success rate?
The reasoning behind the specific threshold will be covered in more detail in the upcoming blog post.
Q: How many operators would be affected by the physical address verification requirement if we use 0.5% as a threshold? A: About 30 operators. There are currently about 18 exit [3] and 12 guard operators that run
0.5% exit/guard capacity
if we ignore the fresh exit groups from 2020. Most exit operators (14 out of these 18) are organizations with public addresses or have their address published in WHOIS anyway.
Please don't assume that all big relay operators are happy with sharing their physical address because most of them already do. Maybe we can poll the big relay operators to find out if they are okay with this? (I don't know if all of them are represented on this list)
In fact, my initial email went to many operators (after the mailing list was not happy with so many recipients I did resend it to the list without the others in TO, so unfortunately you no longer see the full list of recipients), but yes, that is the point of this email - getting feedback from operators, especially from big ones. I a few replied already.
It is definitely an interesting idea, one that I have not thought of at least. But I'm not sure if it would be effective at preventing what it tries to prevent.
Yes, that is basically the key question and since there appears to be a lot of money involved in running malicious relays, they certainly have enough money to buy some office services in some random place and get a physical address verified but one of the other factors of the proposal is also the additional time required for an attacker to go trough the process and that it can no longer be automated completely.
kind regards, nusenu
-- https://mastodon.social/@nusenu
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays