chelsea komlo me@chelseakomlo.com writes:
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.
Hmm, on the above scenario, why would Tor change the version of the onion address if the pubkey and checksum algorithm do not change? The way I see it, the main scenario where we bump the onion address version is if we upgrade the cryptosystem of the identity key or the checksum algorithm. In that case, Facebook will have to migrate to another address anyhow, so moving the version field to the HSDir layer does not really help.
Furthermore, as David said, HS descriptors do have a version field anyway, so we can always take version-specific decisions on the HSDir layer without changing the onion address.
Finally, keeping a version field on the onion address, lets clients take version-specific decisions _before_ contacting HSDirs, which is not possible right now. The use of this is not obvious to me at this point, but I'm sure that onion service applications can find some use. Or it can be used by hidden services that want their clients to use an alternative HSDir hash ring logic (e.g. increase or decrease the default number of responsible HSDirs) by encoding this info in the version field.