[tor-relays] A Simple Web of Trust for Tor Relay Operator IDs

[Georg Koppen]

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 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20211107/aa32edd8/attachment.sig>