[tor-dev] A ContactInfo specification

[nusenu]

Hello,

an earlier version of this has been send to tor-relays [1]
and I got some feedback from irl and relay operators via ML and github
issues.

Now I'd like to hear from the tor developer community.
Please send your feedback until 2017-10-27.

example ContactInfo:
https://atlas.torproject.org/#details/1EBFC733CCD952F7F7616EBBA7BC6B8E6F2F0CBC

Overview
---------

Tor's ContactInfo descriptor 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 other purposes
(website urls, donation information, bitcoin addresses, ...). Making use
of provided information in an automated way is hard since there is no
specification on how this string should look like. This is an
specification to formalize the ContactInfo string.

Motivation (excerpt)
-----------

- collect additional (self-reported) relay metrics (for things like
atlas and https://nusenu.github.io/OrNetStats )
- exmples: How many use tor's Sandbox/OfflineMasterKey/KIST feature?
- This data could provide tor developers with information on how well
tested/how much used new features (like Sandboxes) are before changing
defaults.


The entire document can be found here:
https://github.com/nusenu/ContactInfo-Information-Shareing-Specification

regards,
nusenu



[1]
https://lists.torproject.org/pipermail/tor-relays/2017-October/013274.html

[teor]

Post by nusenu
- collect additional (self-reported) relay metrics (for things like
atlas and https://nusenu.github.io/OrNetStats )
- exmples: How many use tor's Sandbox/OfflineMasterKey/KIST feature?
- This data could provide tor developers with information on how well
tested/how much used new features (like Sandboxes) are before changing
defaults

In general, unstructured text should remain unstructured text.

Automated statistics would be more reliable for these particular use cases.
If the information is sensitive, it can be collected using a safe aggregation
scheme (PrivCount as described in prop280, or similar).

T

[nusenu]

Thank you for the feedback.

Post by teor
In general, unstructured text should remain unstructured text.

Relay ops are free to choose from the available options (unstructured
and structured).

Post by teor
Automated statistics would be more reliable for these particular use cases.
If the information is sensitive, it can be collected using a safe aggregation
scheme (PrivCount as described in prop280, or similar).

I agree that it would be desirable to not require manual steps (=error
prone and likely outdated over time) for items that can be automated.

Most fields on the current list can not be automated though.

Do you consider the following torrc _settings_ too sensitive to publish
by relays (without an aggregation scheme)?

- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)
- Schedulers

[teor]

Post by nusenu

Post by teor
Automated statistics would be more reliable for these particular use cases.
If the information is sensitive, it can be collected using a safe aggregation
scheme (PrivCount as described in prop280, or similar).

I agree that it would be desirable to not require manual steps (=error
prone and likely outdated over time) for items that can be automated.
Most fields on the current list can not be automated though.
Do you consider the following torrc _settings_ too sensitive to publish
by relays (without an aggregation scheme)?
- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)

Yes, these are directly related to relay security, so if they can be linked
to the relay, they should be opt-in.

Post by nusenu
- Schedulers

I don't think this is sensitive information.

T

[nusenu]

Post by teor

Post by nusenu
Do you consider the following torrc _settings_ too sensitive to publish
by relays (without an aggregation scheme)?
- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)

Yes, these are directly related to relay security, so if they can be linked
to the relay, they should be opt-in.

All fields are opt-in and can be linked to the relay if they are
published, but if there are concerns about publishing+collecting that
information I can remove these fields.

[nusenu]

Post by teor

Post by nusenu
- OfflineMasterKey setting (0/1)
- SigningKeyLifetime
- Sandbox (0/1)

Yes, these are directly related to relay security, so if they can be linked
to the relay, they should be opt-in.

I added your note to Sebastian's ticket about publishing key expiry
information in descriptors. I like Sebastian's idea but I also agree to
your opt-in remark - which means that we will likely not get much data
at all (how many relay operators will opt-in vs. the effort to make that
possible).

[nusenu]

Post by nusenu
I added your note to Sebastian's ticket about publishing key expiry
information in descriptors. I like Sebastian's idea but I also agree to
your opt-in remark - which means that we will likely not get much data
at all (how many relay operators will opt-in vs. the effort to make that
possible).

I should include an URL to Sebastian's ticket:

https://trac.torproject.org/projects/tor/ticket/24194