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

[Georg Koppen]

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

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

-------------- 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/20211009/d0579342/attachment.sig>