Add ed25519 URI proof

[Saklad5]

Tor relays currently use both a vestigial RSA1024 key and an ed25519 key. It would make more sense to rely on the latter, especially since there is already a designated location for them.

---

I propose a new proof value, uri-ed25519, which may be validated using the /.well-known/tor-relay/ed25519-master-pubkey.txt path as described in the current tor-relay spec.

[Saklad5]

A corresponding dns-ed25519 proof could also be added, of course.

[nusenu]

Hi and thanks for pushing this forward!

I've added that section in prop326 but ed25519 keys did not find its way into the CIISS spec yet for a few reasons:

• unlike RSA fingerprints, using ed25519 keys as DNS labels is less straightforward because it is not made of hex chars only. Encoding needs to be defined.
• relay operators rarely interact with ed25519 keys, for example ed25519 keys are not displayed on Relay Search
• ed25519 keys have not been added to onionoo yet

So the next steps would be:

1. file a issue on gitlab.torproject.org to add ed25519 keys to onionoo
2. define an encoding that is safe to be used in DNS

I can tackle the second point do you want to file the gitlab issue?

[Saklad5]

1. file a issue on gitlab.torproject.org to add ed25519 keys to onionoo

Do you know which repository that is? I can't seem to find it there.

[nusenu]

Do you know which repository that is? I can't seem to find it there.

https://gitlab.torproject.org/tpo/network-health/metrics/onionoo

[Saklad5]

Done.

By the way, about the DNS proof: couldn't you just use TXT records? It'd be way easier.

[nusenu]

Done.

note this line on the onionoo repo:

STATUS: RUNNING THE SERVICE BUT NOT WORKING ON ENHANCEMENTS RIGHT NOW.

background: Karsten, the author and maintainer of onionoo passed away in 2020 https://blog.torproject.org/in-memoriam-of-karsten-loesing/ mainly for that reason you will not see any substantial changes in onionoo.

By the way, about the DNS proof: couldn't you just use TXT records? It'd be way easier.

We use TXT records for dns-rsa and will use TXT records for dns-ed25519 as well, would you mind elaborating?

Also, do you have a particular use-case for this issue?

[Saklad5]

We use TXT records for dns-rsa and will use TXT records for dns-ed25519 as well, would you mind elaborating?

Why not just have a single TXT record with the same contents as the URI proof? Then you don't need to encode anything in a DNS label.

Also, do you have a particular use-case for this issue?

Nothing too specific: I just want to remove obstacles to no longer having to manage both RSA and ed25519 keys.

[nusenu]

Why not just have a single TXT record with the same contents as the URI proof? Then you don't need to encode anything in a DNS label.

This is not possible because many DNS providers limit the length of TXT records. For example, AWS limits TXT records to 4000 characters. https://aws.amazon.com/premiumsupport/knowledge-center/route-53-configure-long-spf-txt-records/ An operator with 100 relays would be unable fit all ed25519 pubkeys into 4000 chars.

The largest family currently has 178 relays.

[Saklad5]

Ah, that is a problem. In that case, borrow from Sender Policy Framework’s solution: add the ability for a TXT record to include another.

That makes parsing more complex, of course, but not by much. And it wouldn’t be necessary for most people.

[nusenu]

I don't think SPF is a good example to follow in that regard.