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

[George Kadianakis]

chelsea komlo <me at 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>/publish
>>
>> So 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:
>
> 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.
>

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.