Hi,
I'm happy to finally announce version 1 of the ContactInfo Information Sharing Specification:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github.
Tor's ContactInfo field was primarily intended to contain an email address and PGP key fingerprint but since this field accepts an arbitrary string it has been used for multiple other purposes (website urls, donation information, bitcoin addresses, ...).
This is a specification to formalize the ContactInfo string to: - make provided information machine readable (could be used for Relay Search) - improve the ability to contact relay operators - allow the automatic attribution and verification that a relay is operated by a given entity - increase information sharing among tor relay operators
Eran Sandler created a nice and simple to use generator based on the specification: https://torcontactinfogenerator.netlify.app/
If you used the generator and specification in the past, please regenerate your ContactInfo string, so it includes the version field.
I'm particularly looking forward to seeing many use the verifyurl field.
Overview of definied fields
email pgp abuse operatorurl verifyurl keybase twitter mastodon matrix xmpp otr3 ricochet hoster cost uplinkbw trafficacct memory cpu virtualization bitcoin zcash donationurl offlinemasterkey signingkeylifetime sandbox os tls aesni autoupdate confmgmt dnslocation dnsqname dnssec dnslocalrootzone CIISSversion
regards, nusenu
Toralf Förster:
On 7/21/20 7:16 PM, nusenu wrote:
verifyurlWhat is the advantage over the torrc config value "MyFamily" ?
MyFamily is somewhat orthogonal to the idea behind the verifyurl field. MyFamily has an impact on path selection, ContactInfo/verifyurl has not. verifyurl is used to establish a bidirectional verification of the operatorurl.
So if someone sets up a relay claiming to be torservers.net verifyurl can be used to detect that automatically if torservers.net sets verifyurl in their ContactInfo.
On Tue, 21 Jul 2020 20:17:24 +0200 nusenu nusenu-lists@riseup.net wrote:
What is the advantage over the torrc config value "MyFamily" ?
MyFamily is somewhat orthogonal to the idea behind the verifyurl field.
Still not getting what advantage do you propose to ones who choose to also maintain the latter.
It reads like the main purpose of "verifyurl" is to authorize "operatorurl", but even as right now, if there's the same URL across all relays in a consistent MyFamily, what additional authorization does this need and for whom?
MyFamily has an impact on path selection, ContactInfo/verifyurl has not.
Any legitimate example where you would want to claim a fleet of relays as your own, but NOT want that to affect path selection?
verifyurl is used to establish a bidirectional verification of the operatorurl.
So if someone sets up a relay claiming to be torservers.net verifyurl can be used to detect that automatically if torservers.net sets verifyurl in their ContactInfo.
Same already possible with MyFamily, if all other relays do not include that one in their family, it can be assumed to be a "fake".
Roman Mamedov:
On Tue, 21 Jul 2020 20:17:24 +0200 nusenu nusenu-lists@riseup.net wrote:
What is the advantage over the torrc config value "MyFamily" ?
MyFamily is somewhat orthogonal to the idea behind the verifyurl field.
Still not getting what advantage do you propose to ones who choose to also maintain the latter.
It reads like the main purpose of "verifyurl" is to authorize "operatorurl", but even as right now, if there's the same URL across all relays in a consistent MyFamily, what additional authorization does this need and for whom?
Lets say someone sets up a bunch of relays and claims to be the EFF, The Torproject or any other entity they choose. This creates a link between the relay and the entity: (1) relay -> entity
The verifyurl gives everyone, for example users of atlas.torproject.org the possibility to verify what they see. verifyurl create a link in the opposite direction: (2) entity -> relay
(1) + (2) results in a bidirectional link which can not easily be made up.
MyFamily has an impact on path selection, ContactInfo/verifyurl has not.
Any legitimate example where you would want to claim a fleet of relays as your own, but NOT want that to affect path selection?
just to clarify: verifyurl is not trying to replace MyFamily.
verifyurl is used to establish a bidirectional verification of the operatorurl.
So if someone sets up a relay claiming to be torservers.net verifyurl can be used to detect that automatically if torservers.net sets verifyurl in their ContactInfo.
Same already possible with MyFamily, if all other relays do not include that one in their family, it can be assumed to be a "fake".
MyFamily is used to link relay fingerprints. MyFamily alone does not provide any direct way to verify ContactInfo claims. You are assuming that there are other relays. If there are no other relays they can not be used to see the missing MyFamily link between the fake and real relays.
kind regards, nusenu
Great job, except one thing. Can’t providing *any* contact info be obligatory? What’s the point of making specifically the email address required? What are benefits of having it *over other contact info*?
- Automatic verification of some kind? No. That would require client-side system coupled with email accounts.
- Limiting abuse by requiring an email? No. Emails are cheap. Much cheaper than e.g. obtaining a domain and having some specific DNS entry or web page provided. That at least costs some money and confirms that the operator has control over the domain.
- Increasing contact? No. I was offering an email address for some time and the only experience was no single message from a human actually contacting me about Tor. Everything was only spam. Suggesting address rotation or antispam filters is merely an attempt to dismiss the issue, not an answer to it.
I see it as putting more burden on operator for no good reason and making yet another service require an easily abuseable information to be released. I’m aware of of benefits of email (open, “everyone” uses it) and downsides of other options (limited access, abusive or poorly designed websites), but are those really the argument for making this specific information trivially harvestable?
As long as this is optional, it’s not a huge problem. But I do not believe in ignoring stuff simply because temporarily it does not affect me personally.
mpan
mpan a écrit :
- Increasing contact? No. I was offering an email address for some time and the only experience was no single message from a human actually contacting me about Tor. Everything was only spam. Suggesting address rotation or antispam filters is merely an attempt to dismiss the issue, not an answer to it.
- Increasing contact? Yes.
I offer a valid email address on my relays, because if there is any trouble with them I would like to be noticed quickly.
There was also when torproject guys contacted me about fallback directory. How they could contact me if there wasn't address in ContactInfo ?
If I don't put email address in ContactInfo, well, feel free to get reverse DNS of my relay (which is not an exit node), then go on my awesome website (thanks rDNS), then go on the "Contact Me" webpage, then finally get the valid address... No, that's too slow, that's not possible.
IMHO, email is required. It is not about "tracking tor node operators", or "are you a trusted tor node operator with 2FA". It is about what happens if your node is doing sh*t because of mistake in config.
Best regards,
Casper
Thank you for your feedback.
mpan:
Can’t providing *any* contact info be obligatory? What’s the point of making specifically the email address required? What are benefits of having it *over other contact info*?
I'd argue that email is the most accessible? The Tor Project used to use email as a communication channel when trying to reach operators about relay issues.
I'm also fine with making it optional in the upcoming version 2 to lower the barrier for adoption.
For example I find your ContactInfo string still valuable even though you do not provide the email field.
kind regards, nusenu
I'm also fine with making it optional in the upcoming version 2 to lower the barrier for adoption.
My goal is not to make contact info optional. I do understand value of such information. The problem is choosing one specific means of communication as mandatory, instead of letting the operators choose the one that is most convenient to them.
My primary gripe with email is not my privacy. I decided to remove it from my ContactInfo upon noticing that I skim over the messages and discard them in bulk as spam. At this point reaching me through email became unlikely: I would probably delete the message.
On 21/07/20 18:16, nusenu wrote:
Hi,
I'm happy to finally announce version 1 of the ContactInfo Information Sharing Specification:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github.
...
regards, nusenu
Hi Nunsenu
Firstly, thank you for taking the time to look at the issue of malicious relay operators and come up with some potential approaches for addressing it.
If I understand correctly your objective is to increase the level of effort required to run a relay, at least when it comes to the larger relays. I assume that you assume that if more effort is required then malicious relay operators will shut down and go elsewhere?
I do not feel the proposed verification measures will make a malicious relay operators life sufficiently more difficult unfortunately.
Malicious relay operators already expend relatively large amounts of money and presumably effort to do their thing; the example you gave initially talked about a potentially malicious operator providing up to 23% of exit capacity - that must be a very expensive already surely?
I can't help but feel that the issue of malicious operators could perhaps be better addressed by
1) Having a valid email contact address for any given relay as you already suggest; and
2) Having each operator join this mailing-list (using the above email address) and introduce, anonymously or otherwise, themselves and their relay(s).
To have either the guard or exit flags on your relay you would need to complete the aforementioned 2 steps. In cases where there are concerns over a relay or set of relays then there would be a transparent and public forum where those concerns can be both raised and (hopefully) addressed, i.e. this mailing list.
I get that it is not as interesting as a more technical approach but IMHO it would be more effective and could be implemented almost immediately and is actually not that easy to game compared to technical solutions.
Anyway these are just my thoughts.
Thanks again for taking the time to look at the problem.
yours
M Wang
* nusenu:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github.
In section "Defined fields" you write:
Non-ASCII characters are not supported.
I'm not sure if this applies only to keys or also to values? With the availability of IDN (https://unicode.org/faq/idn.html) in email addresses, supporting only US-ASCII values is too limited.
-Ralph
On Fri, Jul 24, 2020 at 9:08 PM Ralph Seichter ralph@ml.seichter.de wrote:
- nusenu:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification This is an effort that started in 2017 as you can see on github.
In section "Defined fields" you write:
Non-ASCII characters are not supported.
I'm not sure if this applies only to keys or also to values? With the availability of IDN (https://unicode.org/faq/idn.html) in email addresses, supporting only US-ASCII values is too limited.
I'd suggest that we should allow UTF-8 for values, at least. It looks like we're standardizing on UTF-8 as our character encoding for directory documents in Proposal 285.
cheers,
In section "Defined fields" you write:
Non-ASCII characters are not supported.
I'm not sure if this applies only to keys or also to values? With the availability of IDN (https://unicode.org/faq/idn.html) in email addresses, supporting only US-ASCII values is too limited.
I'd suggest that we should allow UTF-8 for values, at least. It looks like we're standardizing on UTF-8 as our character encoding for directory documents in Proposal 285.
The state of prop-285 (open) was actually the reason why I did not put UTF-8 into the CIISS :)
Is prop-285 already implemented in tor?
In that case I'm happy to add UTF-8 as recommended.
On Mon, Jul 27, 2020 at 2:05 PM nusenu nusenu-lists@riseup.net wrote:
In section "Defined fields" you write:
Non-ASCII characters are not supported.
I'm not sure if this applies only to keys or also to values? With the availability of IDN (https://unicode.org/faq/idn.html) in email addresses, supporting only US-ASCII values is too limited.
I'd suggest that we should allow UTF-8 for values, at least. It looks like we're standardizing on UTF-8 as our character encoding for directory documents in Proposal 285.
The state of prop-285 (open) was actually the reason why I did not put UTF-8 into the CIISS :)
Oops! Actually, that proposal should be "Accepted". We've gotten behind in labelling them. There's a ticket to label them right at https://gitlab.torproject.org/tpo/core/torspec/-/issues/1
Is prop-285 already implemented in tor?
Partially. Directory authorities reject anything that isn't UTF-8, in dirserv_add_multiple_descriptors().
In that case I'm happy to add UTF-8 as recommended.
cheers, -- Nick
On 21.07.2020 19:16, nusenu wrote:
keybase
Much of this list is verified by keybase. ;-) https://keybase.io/boldsuck
Keybase was purchased from Zoom. Some may want to use https://keys.pub/ instead.
bitcoin zcash
Zcash? If privacy coin then Monero. You can create an openalias for your looong BTC and XMR addresses. My: donate@for-privacy.net or donate.for-privacy.net
tor-relays@lists.torproject.org
-
Casper -
lists＠for-privacy.net -
Mighty Wang -
mpan -
Nick Mathewson -
nusenu -
Ralph Seichter -
Roman Mamedov -
Toralf Förster