Add ed25519 URI proof #16
Comments
|
A corresponding |
|
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?
|
Do you know which repository that is? I can't seem to find it there. |
|
Do you know which repository that is? I can't seem to find it there.
|
|
Done. By the way, about the DNS proof: couldn't you just use TXT records? It'd be way easier. |
|
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?
|
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.
Nothing too specific: I just want to remove obstacles to no longer having to manage both RSA and ed25519 keys. |
|
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.
|
|
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. |
|
I don't think SPF is a good example to follow in that regard. |
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.txtpath as described in the current tor-relay spec.The text was updated successfully, but these errors were encountered: