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

[David Goulet]

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>/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.

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
> 

-- 
IOA3vUozzhhCnEz3vEUUkbz+AJwvgSYAkuxkheMCHHA=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20170130/c1a5b84b/attachment-0001.sig>