Hi,
chelsea komlo:
So if the plan is that onion addresses will not be used directly by end users and there is an abstraction layer that hides things like version upgrade from end users, then going ahead with the current plan sounds good.
However, if there is a chance that end users will consume onion addresses directly, then having this discussion seems like a good idea. The scenario that worries me is something like this:
- Facebook creates a hidden service and distributes this address
- A new hidden service version is created
- Facebook is reluctant to upgrade because this would mean
re-distributing a new onion address to a _lot_ of people. Also, there are problems of securely distributing and verifying new onion addresses- malicious parties could use this opportunity to distribute lookalikes, for example.
When we upgrade key primitives (such as when we move to a PQ scheme), then it will definitely be necessary for HS operators to re-distribute addresses. However, minimizing the need for addresses to change will lower the barrier to use/operate hidden services.
I share your concerns here. I think we could work around this by pulling the version byte out of the base32 encoding, like this:
onion_address = base32(pubkey + checksum) + "-" + version
This would result in onion addresses like this:
tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4g-1.onion
If the HS version changes to version 2, the onion address would only change in the version char:
tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4g-2.onion
This way onion service operators can keep their onion address prefix and users can verify that the new address uses the same public key as the address of the previous version.
What do you think about this?
Cheers