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

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...

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/-/issu...

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...

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 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.

Yeah, that's a good point. I am not sure yet how exactly we want to move forward here, but I do hope we have a clearer picture next year once we actually start the work in this area. [snip] Georg [1] https://lists.torproject.org/pipermail/tor-dev/2021-October/014664.html

---------- Original Message ---------- On Sat, October 9, 2021 at 7:10 AM, Georg Koppen<gk@torproject.org> 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

On Nov 10, 2021, at 10:29, Jonas via tor-relays <tor-relays@lists.torproject.org> 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