[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev