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

[chelsea komlo <me@xxxxxxxxxxxxxxxx>]

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.

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:

1) An onion address is represented by base32(pub_key || checksum)    
2) 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.

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

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev