[tor-relays] Proposal: Restrict ContactInfo to Mandatory Email Address

Mon Oct 23 23:57:06 UTC 2023

Hi Georg,

First of all, thanks to all of you for the effort writing up the proposal!

I saw that email obfuscation was discussed but no solution was proposed. I
want to throw in some ideas about obfuscating the email centrally:
- Let's not publish cleartext email in any public descriptor, and only
publish an obfuscated address, something like
OperatorID at relay-operators.torproject.org or
Fingerprint at relay-operators.torproject.org.
- Only those already operating a relay, using their ContactInfo as "from"
address, can send to these obfuscated addresses and get forwarded to the
actual recipient email. Otherwise the email gets rejected or ignored. (Of
course TorProject folks can also be added to the list of allowed senders.)

This will be very similar to how tor-relays at lists.torproject.org currently
operates. This should reduce spamming as the cost for spamming is quite
nontrivial (go through the hassle of setting up a new relay), while
frictionlessly serving the existing and planned use cases, mainly 1)
broadcast from tor project to all operators, 2) community discussion
between relay operators, and 3) debugging and reaching individual operators
or a small batch of them.

Of course, this solution might be unnecessary (and I agree that
historically there's not much spam). We can balance the benefit and cost --
the marginal cost for adding forwarding logic as part of the future
operator ID / email verification system.
--
Danny

--
Yours sincerely, Xiaoqi Chen

On Sat, Oct 21, 2023 at 3:55 PM Georg Koppen <gk at torproject.org> wrote:

> Hello everyone!
>
> As indicated in our bug tracker a while ago[1] we have some strong
> incentives to redo our ContactInfo field. I've collected all the
> different use cases and combined them in a single proposal, discussing
> some potential concerns and future work we could get built upon it. The
> work is tracked on Gitlab as well[2] feel free to provide feedback there
> or here on the list as a follow-up to this announcement. For your
> convenience the proposal text is included below (if you like reading the
> .md file on Gitlab, see my personal repository for the latest draft[3]).
>
> """
> ```
> Filename: 100-contactinfo-mandatory-email-address.md
> Title: Restricting ContactInfo to Mandatory Email Address
> Author: Georg Koppen
> Created: 2023-10-21
> Status: Open
> ```
>
> ## Overview
>
> This document proposes to change the ContactInfo field from a free text
> field to one that is only allowing an email address. Additionally,
> providing such an email address will be required after this proposal is
> implemented. This is a normative document.
>
> ## Motivation
>
> Being able to reach out to and contact relay operators (bridge operators
> are included in that group) is important for our day-to-day work at Tor.
> While this has been brought up in the past as helpful in our fight
> against malicious relays, it goes well beyond that use case and is
> affecting general network health work, community-building efforts and
> quickly deploying anti-censorship related security fixes among other
> things.
>
> Tor is providing a `torrc` configuration option, `ContactInfo`, which is
> supposed to contain an email address (potentially obfuscated) under
> which the relay operator may be reached. However, in practise this does
> not work very well for two reasons:
>
> 1. `ContactInfo` is a free-form field which allows the operator to
>     include not just email addresses but essentially any kind of text
>     they want. This results in a lot of overhead when trying to contact
>     all operators and failures to do so because not everything added to
>     `ContactInfo` is a way to actually contact operators or undoing
>     `ContactInfo` obfuscation turns out to be too hard.
> 2. `ContactInfo` can be empty as it is not required for all operators
>     and in cases where it is supposed to be required (e.g. for operators
>     running more than one relay) the requirement is not enforced.
>
> Over the years different teams at Tor developed different workarounds to
> the issues mentioned above without addressing them directly. The goal of
> this proposal is to make those workarounds obsolete.
>
> ## Fixing ContactInfo
>
> As briefly mentioned in the [Overview section](#overview) the idea of
> this proposal is deceptively simple: `ContactInfo` will be turned into a
> field allowing just an email address, under which the operator can be
> reached.  Moreover, providing such an address will be a requirement for
> all operators regardless whether they run one relay or many of them, or
> bridges.
>
> Why will we require an email address and not, say, a domain set up
> somewhere or an account on our forum instead? Firstly, a lot of those
> other potential options require a valid email address themselves in the
> first place and would therefore just raise the costs for relay
> operators. Secondly, email still scales way better than other
> alternatives allowing us to reach more people in less time. And,
> thirdly, email addresses are required anyway in other network related
> infrastructure parts, e.g. the RIPE database for IP address space
> allocation comes to mind or abuse contacts for dealing with potentially
> malicious Tor traffic/Tor users.
>
> Even though this proposal will not lay out the envisioned changes at a
> technical level (for that to happen we'll need a corresponding
> [tor-spec] proposal later on) there are a number of details to consider
> mainly stemming from the status quo existing for years and the
> accumulated usage patterns of the `ContactInfo` field "in the wild".
>
> The remainder of this proposal will be devoted to explain those details
> and address potential concerns related to them.
>
> ## Implementation
>
> The C-Tor codebase is in maintenance mode and not accepting any new
> features anymore (with a very narrow set of exceptions). We therefore
> plan to have this change included solely in the upcoming Arti relay
> work. Note: while we'll be using `ContactInfo` throughout this proposal
> it does no mean that the respective configuration option for Arti relay
> will be the same. It could just be [`contact`] or something else. The
> important point is that this proposal applies to whatever is providing
> the argument for the "contact" keyword in the server descriptor then.
>
> Requiring a syntactically correct email address in an Arti relay
> configuration option is necessary but not sufficient for our purposes.
> Otherwise `ContactInfo` values like `nobody at example.com`, which is used
> by some relays and bridges in the Tor network at the time of writing
> this proposal, would be acceptable.  However, in that case there would
> be no way to get into contact with respective relay operators. We intend
> to solve that problem by deploying an email verification service: relays
> without a verified `ContactInfo` value won't be allowed on the network.
>
> ## Concerns
>
> There are some concerns related to this proposal which we should discuss
> and address where needed. The following sections will outline them and
> explain why (and how) we think they are non-issues or can be mitigated.
>
> ### Backward compatibility and breakage of external tooling
>
> What do we do with `ContactInfo` strings that are not email addresses
> already? The main goal should be to make the transitioning process to
> the new `ContactInfo` string as smooth and easy for relay operators as
> possible. The good news is that we plan to have a transitioning tool for
> the overall change of C-Tor relays to Arti relays anyway and having the
> `ContactInfo` change be part of that should help. Running an awareness
> campaign and providing up-to-date documentation to reach operators that
> need to fix (or even set up) their `ContactInfo` manually should further
> minimize the risk of losing relays in the network and volunteers running
> them to begin with.
>
> However, even if it were possible to extract an email address from the
> C-Tor relay configuration of any C-Tor relay or bridge without manual
> intervention by the operator there is another problem to consider: there
> is often additional information available in current `ContactInfo`
> strings, which sometimes external tools got built upon. One well-known
> example for that is [`OrNetStats`] which aims at displaying statistics
> related to relays and bridges in the Tor network.  One important piece
> of it is grouping the displayed information around so-called
> Authenticated Relay Operator IDs (AROIs) were possible, which got
> developed in the [ContactInfo Information Sharing Specification] \(CIISS)
> and is making use of overloading the `ContactInfo` field with additional
> information besides an email address. While we can't avoid breaking
> tools when evolving the `ContactInfo` semantics we can provide ways for
> those tools to get adapted to the new reality. For that we propose to
> create an additional configuration option that includes the non-email
> address information in the `ContactInfo` field and is made public in
> extra-info descriptors. Even though we believe validated email addresses
> as proposed in this proposal together with the planned
> [happy families proposal] and [proposal 347] provide similar benefits as
> the AROI mechanism, and hence make it superfluous, if someone would
> still like to center their relays statistics around AROIs they could do
> so by extracting the necessary information from extra-info descriptors
> after this proposal got implemented.
>
> ### Spam
>
> Exposing an email address without obfuscation in the `ContactInfo` field
> is a potential spam risk which is why some operators have resorted to
> obfuscating it, often in very creative ways. However, we do think that
> those efforts are not effective if we want to retain a way of being able
> to reach operators by email.  Moreover, our own and others' experience
> of running relays and providing an unobfuscated email address as
> `ContactInfo` shows that spam right now is actually not an issue. That
> might change in the future, though, which is why we strongly recommend
> to use a dedicated and long-term email address in the `ContactInfo`
> field. The long-term part is particularly important, as this proposal
> turns that email address into a validated relay operator ID, which is
> valuable for building trust over the longer run.
>
> ## Impact on relay operators and the growth of trust in the Tor network
>
> As can be seen in the previous sections, the proposed changes in this
> document can come with a cost for relay operators. However, we do not
> expect them to have a lasting impact on our relay operator community and
> the health of the network as those changes are mainly accompanied by a
> one-time transition cost that puts a burden on our current relay
> operators. And that one-time cost we try to keep as low as possible.
> Additionally, we might lose or alienate some of our current and
> potential new operators, as they might not want to provide any
> (verifiable) email address at all as a requirement for running relays,
> but rather prefer participation anonymously. However, in order to fight
> malicious relays we need to strengthen our community and get to build
> connections and contacts with each other, which is hard if there is no
> way to get into contact to begin with. As outlined at the begin of this
> document, a lack of contact information makes other day-to-day work at
> Tor hard or impossible as well. Thus, overall we believe providing a
> working email address when running relays is a small cost compared to
> the improvements of the health of our network and the safety of our
> users.
>
> There is another benefit which comes with this proposal: the validated
> email address can essentially work as a relay operator ID (similar to
> the above mentioned AROI). While we do deal with single relays or
> families of them when we are trying to determine whether they pose a
> danger to our users, what we are ultimately aiming at is the operator
> behind them. Having something like a relay operator ID does help with
> that part. But there is more: it allows us to think better about trust
> on the Tor network and how we might be able to implement ideas like
> "operator X is only allowed to run Y% of the Tor network" or "unknown
> operators are only allowed to run Z% of Tor's network capacity", to name
> just two. There are a number of proposals both [trust][torspec 103]
> [related][relay-search 40001] and [not trust-related][team 220] that
> would benefit from having relay operator IDs available.
>
> ## Acknowledgements
>
> Big thanks go to @gus and @ahf for discussions and feedback around this
> proposal idea, which improved this document considerably.
>
> [tor-spec]: https://gitlab.torproject.org/tpo/core/torspec
> [`contact`]:
> https://gitlab.torproject.org/tpo/core/arti/-/issues/870#note_2906252
> [`OrNetStats`]: https://nusenu.github.io/OrNetStats/
> [ContactInfo Information Sharing Specification]:
> https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/
> [happy families proposal]:
>
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/82ba302230911cafd8683d345f8e7ee0e3ad7dda/proposals/321-happy-families.md
> [proposal 347]:
>
> https://gitlab.torproject.org/tpo/core/torspec/-/blob/523404500320ba9700fe5a4751ec31854c86cd1e/proposals/347-domain-separation.md
> [torspec 103]: https://gitlab.torproject.org/tpo/core/torspec/-/issues/103
> [relay-search
> <https://gitlab.torproject.org/tpo/core/torspec/-/issues/103%5Brelay-search>
> 40001]:
>
> https://gitlab.torproject.org/tpo/network-health/metrics/relay-search/-/issues/40001
> [team 220]:
> https://gitlab.torproject.org/tpo/network-health/team/-/issues/220
> """
>
> Thanks,
> Georg
>
> [1] https://gitlab.torproject.org/tpo/core/arti/-/issues/870
> [2] https://gitlab.torproject.org/tpo/community/relays/-/issues/71
> [3]
>
> https://gitlab.torproject.org/gk/policies/-/blob/prop100/100-contactinfo-mandatory-email-address.md?ref_type=heads
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20231023/7f8b824c/attachment-0001.htm>