HAROI: Human Readable Authenticated Relay Operator Identifier
Hi, below is a partial proposal draft for human readable relay operator IDs that are authenticated by directory authorities. If there is any interest in implementing something like this I'll complete the draft and submit it via gitlab. kind regards, nusenu # HAROI: Human Readable Authenticated Relay Operator Identifier A HAROI is a DNS FQDN that can be chosen by a relay operator and linked to one or more relays in a verifiable way. The link is authenticated in the sense that it requires some control over the relay and the FQDN (on the DNS or webroot level). A relay can only be linked to a single HAROI. Relays publish their HAROI via their descriptor. Directory authorities verify the link and publish the verification result in their vote. ## Motivation Many tools in the tor ecosystem display at least some relay (operator) information (nickname, ContactInfo, ...), some examples are: - Tor Browser - Relay Search [1] - Onioncircuits by tails [2] - ExoneraTor [3] - allium [4] unfortunatelly there is no authenticated operator ID available, these tools could display, so they might display misleading information, something that has been exploited in the wild for impersonation attacks. There is a value in giving relay operators the possibility to declare an identifier that is globally unique, consistent and can not be easily spoofed by adversaries so they do not become easy victims of impersonation attacks. The tor ecosystem would benefit from an operator ID that can not be spoofed. This proposal is not replacing the relay ContactInfo. ## Design * A HAROI is optional and not mandatory. * A HAROI is verified by directory authorities in one of two ways, depending on the proof type. In the distant future where relays have no RSA1024 keys, Ed25519 proof types are added. * The used proof type can be selected by the relay operator. Successfully verified proofs are cached by directory authorities for 30 days. After 30 days proofs are verified again. Relay operators that want to make use of HAROI can participate without requiring a domain since many free services offer custom free subdomains (example: GitLab or GitHub pages). ## Proof Types Relay operators, that chose to set a HAROI, can select their preferred a proof type. ### uri-rsa This proof type can be verified by fetching the list of relay RSA SHA1 fingerprints from the FQDN via HTTPS using the well-known URI as defined in proposal 326 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/326-tor... Example: if the FQDN is example.com, the url to fetch the list of fingerprints is: https://example.com/.well-known/tor-relay/rsa-fingerprint.txt The TLS certificate used on the webserver must be from a trusted CA and logged in a public certificate transparency log. For N relays using the same FQDN only a single HTTPS GET request is needed. ### dns-rsa This proof type can be verified by performing DNS lookups. To make use of this proof type the DNS zone MUST be DNSSEC signed. The DNS query is constructed by combining the relay's fingerprint and the FQDN: relay-fingerprint.<FQDN> example: relay-fingerprint.example.com value: “we-run-this-tor-relay” relay-fingerprint is the 40 character RSA SHA1 fingerprint of the tor relay. Each relay has its own DNS record, a single TXT record MUST be returned per relay only. content of the TXT record MUST match: "we-run-this-tor-relay” Each relay requires a single DNS lookup (less scalable than the uri-rsa option). ## Relay Configuration Relay operators can specify their identifier via a torrc option. OperatorIdentifier <FQDN> <proof-type> example: OperatorIdentifier example.com dns-rsa ## Length Limit Although DNS FQDNs can be rather long, we limit HAROIs to 40 characters. (As of December 2021 the longest observed HAROI is 28 characters long.) Operators will not be able to specify a HAROI longer than 40 characters in their torrc. Directory authorities refuse to accept them as well. ## Relays Descriptor Changes This proposal defines a new optional descriptor field that is automatically verified and voted on by tor directory authorities. operatorid <FQDN> <proof-type> ## Directory Authorities Directory authorities refuse to accept domains on the public suffix list [5]. XXX TODO ## Security Considerations Relay operators can trick directory authorities into performing DNS lookups and HTTPS GETs on arbitrary domains. Possible solutions: Directory authorities could required PTR+A DNS records on the same domain as the given FQDN for the relays IP address. [1] https://metrics.torproject.org/rs.html [2] https://gitlab.tails.boum.org/tails/onioncircuits [3] https://metrics.torproject.org/exonerator.html [4] https://yui.cat/ [5] https://publicsuffix.org/list/public_suffix_list.dat -- https://nusenu.github.io
nusenu:
Hi,
below is a partial proposal draft for human readable relay operator IDs that are authenticated by directory authorities. If there is any interest in implementing something like this I'll complete the draft and submit it via gitlab.
I think I am confused a bit. So, how does that relate to the contact information sharing specification you propagate? Is your new proposal an additional thing relay operators should implement on top of the that specification? Or should they choose between the two? What shortcoming does your new proposal solve that is not addressed by the other specification and vice versa? Georg
kind regards, nusenu
# HAROI: Human Readable Authenticated Relay Operator Identifier
A HAROI is a DNS FQDN that can be chosen by a relay operator and linked to one or more relays in a verifiable way. The link is authenticated in the sense that it requires some control over the relay and the FQDN (on the DNS or webroot level). A relay can only be linked to a single HAROI. Relays publish their HAROI via their descriptor. Directory authorities verify the link and publish the verification result in their vote.
## Motivation
Many tools in the tor ecosystem display at least some relay (operator) information (nickname, ContactInfo, ...), some examples are: - Tor Browser - Relay Search [1] - Onioncircuits by tails [2] - ExoneraTor [3] - allium [4]
unfortunatelly there is no authenticated operator ID available, these tools could display, so they might display misleading information, something that has been exploited in the wild for impersonation attacks.
There is a value in giving relay operators the possibility to declare an identifier that is globally unique, consistent and can not be easily spoofed by adversaries so they do not become easy victims of impersonation attacks. The tor ecosystem would benefit from an operator ID that can not be spoofed.
This proposal is not replacing the relay ContactInfo.
## Design
* A HAROI is optional and not mandatory. * A HAROI is verified by directory authorities in one of two ways, depending on the proof type. In the distant future where relays have no RSA1024 keys, Ed25519 proof types are added. * The used proof type can be selected by the relay operator.
Successfully verified proofs are cached by directory authorities for 30 days. After 30 days proofs are verified again.
Relay operators that want to make use of HAROI can participate without requiring a domain since many free services offer custom free subdomains (example: GitLab or GitHub pages).
## Proof Types
Relay operators, that chose to set a HAROI, can select their preferred a proof type.
### uri-rsa
This proof type can be verified by fetching the list of relay RSA SHA1 fingerprints from the FQDN via HTTPS using the well-known URI as defined in proposal 326 https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/326-tor...
Example: if the FQDN is example.com, the url to fetch the list of fingerprints is:
https://example.com/.well-known/tor-relay/rsa-fingerprint.txt
The TLS certificate used on the webserver must be from a trusted CA and logged in a public certificate transparency log.
For N relays using the same FQDN only a single HTTPS GET request is needed.
### dns-rsa
This proof type can be verified by performing DNS lookups. To make use of this proof type the DNS zone MUST be DNSSEC signed.
The DNS query is constructed by combining the relay's fingerprint and the FQDN:
relay-fingerprint.<FQDN>
example:
relay-fingerprint.example.com value: “we-run-this-tor-relay”
relay-fingerprint is the 40 character RSA SHA1 fingerprint of the tor relay. Each relay has its own DNS record, a single TXT record MUST be returned per relay only.
content of the TXT record MUST match:
"we-run-this-tor-relay”
Each relay requires a single DNS lookup (less scalable than the uri-rsa option).
## Relay Configuration
Relay operators can specify their identifier via a torrc option.
OperatorIdentifier <FQDN> <proof-type>
example:
OperatorIdentifier example.com dns-rsa
## Length Limit
Although DNS FQDNs can be rather long, we limit HAROIs to 40 characters. (As of December 2021 the longest observed HAROI is 28 characters long.) Operators will not be able to specify a HAROI longer than 40 characters in their torrc. Directory authorities refuse to accept them as well.
## Relays Descriptor Changes
This proposal defines a new optional descriptor field that is automatically verified and voted on by tor directory authorities.
operatorid <FQDN> <proof-type>
## Directory Authorities
Directory authorities refuse to accept domains on the public suffix list [5].
XXX TODO
## Security Considerations
Relay operators can trick directory authorities into performing DNS lookups and HTTPS GETs on arbitrary domains.
Possible solutions: Directory authorities could required PTR+A DNS records on the same domain as the given FQDN for the relays IP address.
[1] https://metrics.torproject.org/rs.html [2] https://gitlab.tails.boum.org/tails/onioncircuits [3] https://metrics.torproject.org/exonerator.html [4] https://yui.cat/ [5] https://publicsuffix.org/list/public_suffix_list.dat
Hi, Georg Koppen:
I think I am confused a bit. So, how does that relate to the contact information sharing specification you propagate? Is your new proposal an additional thing relay operators should implement on top of the that specification? Or should they choose between the two? What shortcoming does your new proposal solve that is not addressed by the other specification and vice versa?
On a technical level CIISS proofs [1] and HAROI proofs are the same, the main difference is the integration into tor and the verification of proofs by directory authorities. The proof field in CIISS would eventually become obsolete should HAROIs get implemented in tor, but since the proof is the same, relay operators do not have to setup some new kind of proofs when HAROI is implemented (>1400 relays, >50% exit probability have properly setup their proof already and more will follow soon). The CIISS proof will continue to serve its purpose until HAROI is deployed in tor releases since it naturally takes a long time until all relays run a supported tor version that would support it. The main benefit of HAROI is the central verification of proofs by directory authorities instead of requiring everyone to verify the proofs themselves. This is better for efficiency and will reduce the load on proof endpoints (DNS and webservers). I hope that helps clarifying the relation between HAROI and CIISS proof field. Should you have any more questions do not hesitate to ask. kind regards, nusenu [1] https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/#proo... -- https://nusenu.github.io
to avoid that long name: Human Readable Authenticated Relay Operator Identifier (HAROI) I'm replacing it with the slightly shorter: Authenticated Relay Operator ID (AROI) and use that wording across all OrNetStats pages now: https://nusenu.github.io/OrNetStats/w/misc/families-by-bandwidth.html kind regards, nusenu -- https://nusenu.github.io
related rC3 presentation: title: Towards a more Trustworthy Tor Network when: 2021-12-28, 17:00 CET where: https://streaming.media.ccc.de/rc3/csh kind regards, nusenu -- https://nusenu.github.io
participants (2)
-
Georg Koppen -
nusenu