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 tolimit 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 clearerhttps://github.com/nusenu/tor-relay-operator-ids-trust-information/blob/main/README.md#motivation
Thanks!
So, what is in your opinion the larger picturehere?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.htmlIt seems to me this is not unimportant and as your proposal is essentially raising the bar yet again for running relaysThis 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 intenthttps://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 couldthink 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 trustinformation.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
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays