Hey,
On 01/28/2017 10:16 AM, segfault wrote:
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?
I think this is could be an option if the HS version is needed in the client request when fetching the descriptor from the HSDir. It is my understanding that the HS version is already encoded in the descriptor, so theoretically the version can be removed from the client request entirely.
The scheme you describe above still may have distribution problems, and possibly still puts responsibility on the end user. For example, say the following happens:
1. Tor releases HS version 5 (a new version) 2. The New York Times HS has not yet upgraded, and remains on version 4 for a period of time.
As a Tor client, how do I know whether to use
tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4g-4.onion or tbi5tdxbosiotphawjyu7f5pw5tlnvbvfjrj7meskbsnwr2bqbu2t4g-5.onion
? Either my Tor client can try version 5 by default (the highest version supported) and then fall back to version 4, or it can be the responsibility of the end user to check whether the New York Times has upgraded. Both of these scenarios are prone to error, and the second is difficult to scale. If we can leave out the HS version from the client request and publish HS versions only in the descriptor, it seems like these issues could be mitigated.
Let me know what you think, or if the above scenarios can be mitigated in other ways. Chelsea