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:
It 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 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 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] [tor-dev] A Simple Web of Trust for Tor Relay Operator IDs
