Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
> On Nov 10, 2021, at 10:29, Jonas via tor-relays > wrote: > > I could easily run thousands of [relays] across many ASes ... However, > providing proof of identity or anything which ties to my real world identity > is a non-starter. I'm in a similar situation, though it would be "dozens" instead of "thousands." I understand the argument in favor of restricting relays to well-known, identifiable operators but I also see a possible flaw in the logic. The more you restrict who can run a relay, the fewer relays there will be. Yet, no amount of restriction will eliminate all malicious relays. (Even requiring relay operators to submit DNA samples to prove they are first-degree relatives of Tor Project board members wouldn't guarantee perfection.) Given that malicious relays will always exist, there is merit in the idea of having the largest possible pool of relays against which bad actors would have to compete. With a low bar for entry, bad actors could even end up competing against other malicious operators, and ordinary users would still come out ahead. Unfortunately, I fear that reliable numbers would be hard to come by. But I think that there might be many people in the same position that Jonas and I are in: willing and able to run a significant number of high-value relays but only if we can do so ignoring or circumventing real-identity measures. Bad actors will disproportionately ignore or subvert such measures; worthy volunteers will be locked out. It is human nature, when faced with a threat, to respond by asserting control. I wonder if, in this case, decentralization and increased participation might be better strategies. --Ron ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
> This proposal seems to come from a > desire of power and control over the network, not > actually improving "anonymity" for users That sounds more like a personal reaction to not wanting to be identified rather than a helpful statement about other people's motivations, which I'd stay away from, however, seeing the time, effort and care people from the tor project and people like nusenu seem to invest, I don't think your statement is appropriate. Even if there are other attack vectors, it seems to have been shown that malicious relays are in fact used for nefarious purposes, but you seem to wave that off because it doesn't fit with your desire to avoid identity requirements. I think it would be better to pose it as a question that perhaps asks about the trade-offs for defending against this kind of network attack versus potential damage it can cause compared to the other attacks you think are more trivial to launch (but that still sounds like it's debatable and is skewed language so that it fits your fundamental objection about anonymity of relay operators). You should be more fair to the merits and benefits of these requirements while questioning what can be done about their negative ramifications. Maybe the conversation you want to encourage is if/how anonymity for relay operators complements or conflicts with end-user anonymity? As the network matures, clearly that is a tension that is very uncomfortable (and is by no means unique to tor). Maybe something like I2P or Freenet can serve as a contrast or would be more interesting to you. > Dose this run into legal regulations in the EU and > other places that will clearly demonstrate that "control" means the tor > project is actively managing the network? IANAL, but I doubt it, at least not any more than that argument can already be made today-- and who is to say if that's a problem even if it's true. > The secondary concern is the safety of that identity data collected by the > tor project or its designated "authorities". It builds a network graph of > relay operators and their ties to the tor project. This network graph > makes it trivial to figure out whom to surveil and where to apply pressure > to do actions to benefit "the state". This is a good argument/question to ask IMO... > The controlled shutdown of v2 onions raised many eyebrows in our legal > dept. It de facto states the tor project is controlling the network and > operating as an online service provider or online platform. ...but statements like this sound more like veiled complaining and straw man-like ways to convince yourself of someone else's intentions when they may in fact be trying to do what they can to improve the network for everyone (though there was some loss with v2 onions, it's not like the tor team didn't offer strong justifications for removing them - justifications that are very much related to protecting anonymity). Isn't there space for participating anonymously in these so-called identity requirements like a trust network or myfamily configuration? IIRC there is. Maybe you can ask about ways that there could be more of that. Also, if you want to run thousands of nodes, I'd wonder if the easiest path that links you to them, at least for someone like a state actor, may not necessarily be through these mechanisms you object to. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
-- Original Message -- On Sat, October 9, 2021 at 7:10 AM, Georg Koppen wrote: Thanks for the proposal it provides good food for thought. You are right there is the MR on Gitlab now but I don't think your proposal is torspec material. Nor do I think a lot of relay operators are watching the discussion there. However, as they are the ones who are most affected by the proposal it's smart to find a better place for discussing its ideas. Hence this thread on tor-relays@. ---response starts here--- As a bridge operator, I stopped the plan on running relays due to the identity requirements. I could easily run thousands of bsd-based (personal choice) across many ASes or cause many to appear through steep discounts at my employer. However, providing proof of identity or anything which ties to my real world identity is a non-starter. Prior conversations with The Tor Project Inc have been encouraging about running many relays and/or offer discounts to relay operators through my employer. I'm greatly concerned with proposals like this. I fully understand the concern over "malicious relays". What little I understand of the published literature, there are far more accurate, lower resource attacks against tor than running many modified relays. This proposal seems to come from a desire of power and control over the network, not actually improving "anonymity" for users. Dose this run into legal regulations in the EU and other places that will clearly demonstrate that "control" means the tor project is actively managing the network? The secondary concern is the safety of that identity data collected by the tor project or its designated "authorities". It builds a network graph of relay operators and their ties to the tor project. This network graph makes it trivial to figure out whom to surveil and where to apply pressure to do actions to benefit "the state". The controlled shutdown of v2 onions raised many eyebrows in our legal dept. It de facto states the tor project is controlling the network and operating as an online service provider or online platform. These are my current concerns and thoughts. Feedback and pointers to more reading are welcomed. Merci, Jonas ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
Hi, Sounds good. I read a couple of days ago[1] that there will be a new iteration of your draft available (shortly). I am happy to give further feedback while going over the new version, once it is ready. the changes are already done, but were less significant than expected since some comments turned out to be a misunderstanding. I'd still like to add a diagram that might help with making the roles and possible links clearer. We just wrote a proposal for a sponsor where we have one activity about creating a database about relays and annotating them with trust information. What is your motivation to annotate at the individual relay level instead of assigning information at the operator level? If we really want to move forward with the plan to limit the fraction of network traffic untrusted relays can see, then we need to track trust on the relay level. Otherwise how should tor take trust into account when building its paths? Yes, in the end you need relay identifiers but that does not mean you have to track trust on the relay ID level and it would feel strange to me to assign different trust levels to two relays operated by the same person (in an initial simple trust scheme). In my opinion it is reasonable to say "I trust these 40 exit operators", when they add or replace their relays I still trust their new relays if there is a verifiable link between their operator and relay ID. The operator IDs to relay IDs can be mapped automatically, I don't see any benefit in doing that manually, quite contrary, doing it manually is likely more error prone and a lot more time consuming and likely even less transparent. Operators do not play a role here The operator of a relay is the strongest and first trust criteria for me. "I trust relay X more than relay Y because I know and trust Alice and Alice has proven she runs relay X and I don't know anything about relay Y's operator" If a relay's operator is not a factor in your trust decision, I'm curious what is your input for deciding whether to trust relay X or not? E.g. Roger could note all the relay operators he knows and trusts, the same could Gus do and I and so on. How you you know whether a relay is operated by some given entity (at scale)? The scale comes from different folks knowing different relay operator (groups) and from doing the annotation over time taking things like e.g. MyFamily settings into account. I'm wondering why you would prefer to manually assign relays to operators when you can automate that process? to summarize: we seem to have different input factors for trust, I primarily use operator's trust and reputation to decide whether to trust a given relay and I don't want to manually link relays to their operator (have done that before and don't want to go back to that ;). you have some other input factors in your trust scheme and you prefer to manually maintain a database with relay IDs + trust info. kind regards, nusenu bonus content: ;) There are other areas where the focus on relays instead of operators is essential. E.g. we do not kick out operators from the network when doing bad-relay work. there have been multiple cases where large fractions of a family were found to be malicious and the reaction was (in my opinion correctly) to remove the entire set relays have already been rejected based on their ContactInfo - see the CypherpunkLabs example where the malicious actor used another operators (unverifiable) ContactInfo and in the end all of them (including the non-malicious once) got removed. https://nusenu.medium.com/tracking-one-year-of-malicious-tor-exit-relay-activities-part-ii-85c80875c5df Anyway this thread is not about rejecting bad relays. -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
nusenu: I think I have some general questions to begin with: 1) What part should the proposal you brought up play in the overall goal of limiting impact of malicious relays? You write """ Therefore we propose to publish relay operator trust information to limit the fraction and impact of malicious tor network capacity. """ but I don't understand how *publishing* that information is supposed to limit malicious relays. you are right, publishing it alone does not change anything it is just the important first step. I updated the text to make this part clearer https://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#motivation Thanks! So, what is in your opinion the larger picture here? It is outlined by Roger here: https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001 https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html It seems to me this is not unimportant and as your proposal is essentially raising the bar yet again for running relays This document does not introduce any additional requirements when setting up a tor relay. Well, yes, there are no hard criteria for e.g. rejecting relays if they don't do X. However, we should be aware of potential implicit pressure to put more work into running a relay, in particular if, say, trust information is getting exposed on relay-search or is at some point taken into account when building paths through the network. https://example.com/.well-known/tor-relay/trust/requirements.txt This file contains the rules they apply before they add a new entry to the list of trusted operator IDs in english. How is that supposed to work in practice? There are some English sentences saying what the TA thought reasonable as requirements which means they have to be manually reviewed so one actually understands what trust in that case means? That was not fleshed out yet, but I took your feedback to make it a lot simpler: Now a TA's trust simply means we assert this operator does run tor relays WITHOUT malicious intent https://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#trust-anchor-ta Okay. 3) I like the whole proposal outline with a threat model, security considerations and so on. That's really helpful for thinking about this topic. I wonder whether you think there should actually be a "Network health considerations" section, too, in your proposal because one could think it might have potential effects e.g. on relay diversity. I added a few remarks in the last section that TA selection will have an impact on "social diversity" Sounds good. I read a couple of days ago[1] that there will be a new iteration of your draft available (shortly). I am happy to give further feedback while going over the new version, once it is ready. We just wrote a proposal for a sponsor where we have one activity about creating a database about relays and annotating them with trust information. What is your motivation to annotate at the individual relay level instead of assigning information at the operator level? If we really want to move forward with the plan to limit the fraction of network traffic untrusted relays can see, then we need to track trust on the relay level. Otherwise how should tor take trust into account when building its paths? Operators do not play a role here and this is not going to change. Sure, trust in the operator plays a crucial role in this process but that's a means to our end (that is trusting or not trusting relays). There are other areas where the focus on relays instead of operators is essential. E.g. we do not kick out operators from the network when doing bad-relay work. Rather, it's always relays that are decided upon (yes, again, operator information is an important bit in that part of our work, but not the only one; similarly as above it'S a means to the end, this time figuring out whether to keep a particular relay in the network or not). Additionally, annotating relays nicely dovetails with our plan to set up a database with information about all the relays (not the operators) we have/had in the network. We want to do that for a variety of purposes as the current situation is not optimal (as you might know). Adding some additional column(s) conveying trust information regarding relays seems straightforward, at first glance at least (actual work has not started yet either in that area). E.g. Roger could note all the relay operators he knows and trusts, the same could Gus do and I and so on. How you you know whether a relay is operated by some given entity (at scale)? The scale comes from different folks knowing different relay operator (groups) and from doing the annotation over time taking things like e.g. MyFamily settings into account. However, one risk we thought worth mentioning to the sponsor was that publishing annotations aka trust
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
I think I have some general questions to begin with: 1) What part should the proposal you brought up play in the overall goal of limiting impact of malicious relays? You write """ Therefore we propose to publish relay operator trust information to limit the fraction and impact of malicious tor network capacity. """ but I don't understand how *publishing* that information is supposed to limit malicious relays. you are right, publishing it alone does not change anything it is just the important first step. I updated the text to make this part clearer https://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#motivation So, what is in your opinion the larger picture here? It is outlined by Roger here: https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001 https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html It seems to me this is not unimportant and as your proposal is essentially raising the bar yet again for running relays This document does not introduce any additional requirements when setting up a tor relay. https://example.com/.well-known/tor-relay/trust/requirements.txt This file contains the rules they apply before they add a new entry to the list of trusted operator IDs in english. How is that supposed to work in practice? There are some English sentences saying what the TA thought reasonable as requirements which means they have to be manually reviewed so one actually understands what trust in that case means? That was not fleshed out yet, but I took your feedback to make it a lot simpler: Now a TA's trust simply means we assert this operator does run tor relays WITHOUT malicious intent https://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#trust-anchor-ta 3) I like the whole proposal outline with a threat model, security considerations and so on. That's really helpful for thinking about this topic. I wonder whether you think there should actually be a "Network health considerations" section, too, in your proposal because one could think it might have potential effects e.g. on relay diversity. I added a few remarks in the last section that TA selection will have an impact on "social diversity" We just wrote a proposal for a sponsor where we have one activity about creating a database about relays and annotating them with trust information. What is your motivation to annotate at the individual relay level instead of assigning information at the operator level? E.g. Roger could note all the relay operators he knows and trusts, the same could Gus do and I and so on. How you you know whether a relay is operated by some given entity (at scale)? However, one risk we thought worth mentioning to the sponsor was that publishing annotations aka trust information might alienate relay operators from contributing to the network as they might feel their contribution is not enough or not valued enough. I think that boils down to TA diversity. You probably want to use more TAs than Roger, Gus and you. Well regarded organizations like the EFF, CCC, known people at hackerspaces, ... can probably help you span a global network, but even these are at some level trusted by some and untrusted by others. If user's get the impression that the tor network is run by Roger's friends only their perceived risk that they might collude against someone else might increase. kind regards, nusenu -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
nusenu: >> Thanks! You don't have an email-friendly version of that proposal by >> chance, which one could reply to inline? > > there is just the .md file. > > You can also comment inline on the md file on gitlab. > > Due to David's comment on tor-dev there is a merge request on gitlab: > https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/49 Thanks for the proposal it provides good food for thought. You are right there is the MR on Gitlab now but I don't think your proposal is torspec material. Nor do I think a lot of relay operators are watching the discussion there. However, as they are the ones who are most affected by the proposal it's smart to find a better place for discussing its ideas. Hence this thread on tor-relays@. I think I have some general questions to begin with: 1) What part should the proposal you brought up play in the overall goal of limiting impact of malicious relays? You write """ Therefore we propose to publish relay operator trust information to limit the fraction and impact of malicious tor network capacity. """ but I don't understand how *publishing* that information is supposed to limit malicious relays. So, what is in your opinion the larger picture here? It seems to me this is not unimportant and as your proposal is essentially raising the bar yet again for running relays and relay operators should therefore have kind of an understanding whether the additional effort they have to do is worth it. 2) You write: """ All entities that publish trust information should publish their trust requirements under this well-known URL: https://example.com/.well-known/tor-relay/trust/requirements.txt This file contains the rules they apply before they add a new entry to the list of trusted operator IDs in english. """ How is that supposed to work in practice? There are some English sentences saying what the TA thought reasonable as requirements which means they have to be manually reviewed so one actually understands what trust in that case means? Additionally, when you say """ trust information must be machine readable """ how does that work for a TA having as requirement for trusting X e.g "has a Twitter account" vs a TA saying I trust X because "I have meet the operator in person"? Would the machine readability imply that both paths leading to X would get the same trust because the trust requirements are essentially not taken into account when computing trust as I understand it? 3) I like the whole proposal outline with a threat model, security considerations and so on. That's really helpful for thinking about this topic. I wonder whether you think there should actually be a "Network health considerations" section, too, in your proposal because one could think it might have potential effects e.g. on relay diversity. To give you some context for that: We just wrote a proposal for a sponsor where we have one activity about creating a database about relays and annotating them with trust information. E.g. Roger could note all the relay operators he knows and trusts, the same could Gus do and I and so on. However, one risk we thought worth mentioning to the sponsor was that publishing annotations aka trust information might alienate relay operators from contributing to the network as they might feel their contribution is not enough or not valued enough. So, maybe it's worth for your proposal to think about possible impact for network health (e.g. diversity), too? It's not that the fight against bad relays comes without cost to other parts related to network health and we should make sure those costs are on the table as well to get the full picture when evaluating possible solutions to a problem. Georg OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
Thanks! You don't have an email-friendly version of that proposal by chance, which one could reply to inline? there is just the .md file. You can also comment inline on the md file on gitlab. Due to David's comment on tor-dev there is a merge request on gitlab: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/49 kind regards, nusenu -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
nusenu: > Hi, > > I wrote down a spec for a simple web of trust > for relay operator IDs: > > https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-operator-ids/proposals/ideas/xxx-simple-relay-operator-wot.md#a-simple-web-of-trust-for-tor-relay-operator-ids Thanks! You don't have an email-friendly version of that proposal by chance, which one could reply to inline? No worries, if not, I just did not find any by looking cursorily. I'd like to discuss your ideas on this mailing list given that you sent a link to the proposal to it and it's a topic for relay operators. I can try to copy the relevant snippets out of the .md file into this thread in that case. Georg > > This is related to: > https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001 > > https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html > > kind regards, > nusenu > OpenPGP_signature Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] A Simple Web of Trust for Tor Relay Operator IDs
Hi, I wrote down a spec for a simple web of trust for relay operator IDs: https://gitlab.torproject.org/nusenu/torspec/-/blob/simple-wot-for-relay-operator-ids/proposals/ideas/xxx-simple-relay-operator-wot.md#a-simple-web-of-trust-for-tor-relay-operator-ids This is related to: https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001 https://lists.torproject.org/pipermail/tor-relays/2020-July/018656.html kind regards, nusenu -- https://nusenu.github.io ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
