On 28 Jan (00:25:04), chelsea komlo wrote:
Hey!
Here is some extra pressure for you ;).
:) thanks, I will try!
Before starting, someone today very kindly pointed me to Prop 271, the naming system API for Tor Onion services. Overall, my larger concern is whether adding the version in the onion address makes both using and distributing onion addresses harder. If the long-term plan is for onion addresses to not be used directly, then having the version in the onion address is completely fine as this wouldn't present a barrier to entry for end users.
The HSDir fetch/post URL has gone in 0.3.0 (feature freeze today in theory ;) with the version in it:
--> /tor/hs/<version>/publishSo few things. First, if we don't have the version in the onion address, this means the client needs to try to fetch the descriptor for multiple version that is starting at the highest it knows and then going down as it's failing. That, I'm really not too keen to this, uneeded load on the network.
Yep, fair. So the idea of "fetch multiple descriptors, where a descriptor is for a single version," isn't viable for performance reasons.
Second thing is that HSDir might not all support the same version by the time we roll out prop224 thus the importance of having it in 0.3.0 (a version *before* the next gen release). Even with that, this is going to be an interesting experiement to have a set of HSDir supporting v3 and a set not supporting it because we kind of have this requirement of using 3 nearest relays for a replica but what if one of them doesn't support v3?
Yeah, that is hard. Although I'm not entirely sure how this complexity is correlated with how the client consumes the HS version...
Third thing, we could have a fix for this with a single descriptor supporting multiple version but then this has implication outside the onion address discussion and unfortunately 0.3.0 material again (that freezes today).
So I'm eager to hear your idea on this! But it's important to keep in mind that 0.3.0 has already some building blocks with some version restrictions :S. Changing those would mean delaying adoption by a 6 months (and it could be OK!).
Yeah! 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.
If you think it is worth pursuing this discussion, I can start a new thread to discuss this further. One idea that seems viable is for descriptors to specify multiple supported HS versions (taking into account the points you and George have already made). In short, the scheme could be something like this:
- An onion address is represented by base32(pub_key || checksum)
- A descriptor specifies a list of versions supported by the HS with
that address (a descriptor can represent only one address/public key but multiple versions) 3) The client selects the highest available version supported
The proposed change to section 2.2.6 in prop 224 (URLS for anonymous uploading and downloading) would be for the publish URL to be HTTP POST to /tor/hs/publish, and HTTP GET to /tor/hs/<z>, where <z> is a base64 encoding of the hidden service's blinded public key. This would also mean that HSDir code won't need to change when new versions are added.
Quick follow up after George's response. This scheme doesn't work if the protocol is changed with new crypto. Today we use ed25519 blinded keys but tomorrow we could be in a PQ world so we are kind of putting ourself in a bad position with this URL scheme and would have to change more things HSDIr side at next version.
I do like the idea of "if we version++, how can we provide a way to not have the onion address to change" but imo I think that the day we'll move to v4, it will _most_ likely be for new crypto like George mentionned changing the address.
Finally, for a client to *not* know the version also prevents us to act *before* any fetch is done client side (again like George said). HSDir fetch is one thing but if we ever implement the Name Transport Plugin idea for instance, it will be extremely valuable imo that we can extract the version protocol from the onion there. That's one of the few things that can happen pre-fetch. It could be that at version X, client needs to do some extra steps before fetching the descriptor for instance. Etc...
Thanks for the feedback! David
But again, this change probably isn't necessary if onion addresses will live below an abstraction layer!
I apologize if this isn't good timing with feature freezes- I'll follow your lead with this! Chelsea