[tor-dev] HAROI: Human Readable Authenticated Relay Operator Identifier

Wed Dec 8 08:18:12 UTC 2021

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-relay-well-known-uri-rfc8615.md#well-knowntor-relayrsa-fingerprinttxt 
> 
> 
> 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
> 
> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20211208/1e6477d4/attachment-0001.sig>