[tor-dev] [RFC] Proposal for the encoding of prop224 onion addresses

[segfault]

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:
> 
> 1) Facebook creates a hidden service and distributes this address
> 2) A new hidden service version is created
> 3) 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