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