[tor-relays] Using ContactInfo to publish additional relay properties in a standardized way (opt-in)

[nusenu]

Status: WIP
please send your comments until 2017-10-27


I'm writing this with the following motivation:

- make it easier for current and future relay operators to find (rarely
used) hosters for tor relays by increasing the information sharing
between relay operators.
	-> help the tor network grow
- improve geo- and autonomous system diversity on the tor network (more
diverse is better)
- collect additional (self-reported) relay metrics (for things like
atlas [1] and OrNetStats [2])
https://atlas.torproject.org
https://nusenu.github.io/OrNetStats
	exmples:
		How many
		- use tor's Sandbox?
		- run in OfflineMasterMode?
		- make use of KIST?
		- do auto-updates?
 This data could provide tor developers with information on how 	well
tested/how much used new features (like Sandboxes) are before changing
defaults.
- improve the ability to contact relay operators (automatically)
- make provided information machine readable
- provide the foundation for an automated contactInfo verification bot
	mutually verified email addresses (and other contact options) could be
displayed differently on atlas.torproject.org
- make t-shirt delivery easier since contact information is potentially
already verified
- increase the ability to detect undeclared relay groups / make hiding
relay groups harder
- make hosting costs visible
- potentially detect relay operators impersonating other operators by
using their email address


Should 10% cw fraction and at least 50 operators use any of the defined
fields I'll ask irl (atlas maintainer) to get that specific field added
to atlas (separately from the contactinfo string).


Example ContactInfo String
--------------------------

email:user[]example-operator.com hoster:https://example-hoster.com
uplinkbw:100 trafficacct:unmetered cost:10 virtualization:xen



Considerations
----------------

-  increases exposure of relay operators
The machine readable information could be used by spammers and to target
relay operators.
Operators concerned about this can omit contact information
but it should not be hard to create a new email address for the purpose.

- more information makes targeted exploitation easier / more silent
Attackers could use the additional information provided in these fields
to specifically
target only vulnerable systems.
Operators concerned about sharing configuration information should omit
this type of information,
but can share other information.

- increased descriptor size and directory traffic
The contactinfo field size could potentially grow because of this
specification.
This should be mitigated with the use of directory data compression and
diffs available since tor 0.3.1.

- ContactInfo size constraints
According to the manual [2] there is no explicit ContactInfo size limit
but there is a descriptor size limit. The max. descriptor size is 20000
bytes [3]. The family size and exit policy
are two other relevant inputs.


[2] https://www.torproject.org/docs/tor-manual.html.en#ContactInfo
[3] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n364


List of information fields
----------------------------

I started to collect possible fields here:

https://github.com/nusenu/ContactInfo-Information-Shareing-Specification#defined-fields


looking forward to your feedback,
nusenu

Document location:
https://github.com/nusenu/ContactInfo-Information-Shareing-Specification


-- 
https://mastodon.social/@nusenu
twitter: @nusenu_

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20171014/6f7bb96e/attachment.sig>