[metrics-team] v3 unique onion address estimates

[David Goulet]

On 18 Dec (21:49:13), Karsten Loesing wrote:
> On 2019-12-18 17:04, David Goulet wrote:
> > On 18 Dec (10:59:51), Roman Brunner wrote:
> >> Hi metrics team,
> >>
> >> There exists an estimate for unique v2 .onion addresses for v2 onion
> >> services. However, for v3, no such estimate exists.
> >> Lately, the estimates for the v2 addresses started to decrease steadily,
> >> which I assume to be because of more and more services make the switch to
> >> v3. Hence it would be interesting to know how many distinct v3 addresses
> >> are available.
> >> Is there anything planned to extend this estimate to v3 addresses? And
> >> towards a possible implementation for v3: do v3 addresses pose any
> >> additional challenges compared to v2 or could the current statistics
> >> collection be extended?
> > 
> > Hi!
> > 
> > So yes, v3 are more challenging. The reason is because with v3 descriptors
> > (posted at the HS directory), do not contain the .onion address. They instead
> > have what we call a "blinded key" which can only be derived depending on a
> > time period, a shared random value (created within the consensus every 24h)
> > and the master identity key of the service (the v3 .onion).
> > 
> > And thus, the client can generated that blinded key by knowing the .onion and
> > request the blinded key at the directory. One thing that is working for us,
> > the time period are fixed over a day and we know when the shared random is
> > created as well.
> > 
> > Thus the only way we can estimate is by keeping an aggregate count of similar
> > blinded keys a directory sees every 24h (up to the new shared random
> > creation). And also, another complication, services publish 2 descriptors at
> > all time that is using the current and previous shared random value in order
> > to accomodate client with skewed clock.
> > 
> > We'll be able to only estimate the number of v3 addresses that the network
> > sees. And that that number will be obsfuscated for privacy reasons, like we do
> > with v2.
> > 
> > More info: https://trac.torproject.org/projects/tor/ticket/23126
> > 
> > All in all, we haven't done this feature in tor just yet.
> 
> Thanks, David, for summarizing the current state on the little-t-tor
> side. I had started drafting a response to this question, and these
> details about version 3 onion services were something I didn't know and
> would have asked for your input anyway.

Awesome summary Karsten from Metric side!

> 
> So, assuming that that ticket above will be resolved some day, there are
> still a few more steps until we have graphs on version 3 .onion addresses:
> 
>  - We need to wait until enough relays have upgraded to the version that
> reports version 3 .onion address counts. This can take weeks or even
> months. Not the end of the world, but worth considering.

To complement, on January 2020, the long term stable tor 0.2.9 will become end
of life and we will start rejecting them from the network not long after.

https://trac.torproject.org/projects/tor/ticket/32672

This will _finally_ bring the end of relays not supporting onion service v3.

> 
>  - We also need to extend the code that aggregates numbers for Tor
> Metrics to also aggregate version 3 .onion address counts. It's not the
> simplest aggregation code we have, so that this might take a week or two
> of coding time.
> 
>  - And we need to add or extend graphs to show the new numbers. This one
> is rather simple. (We just added two graphs on BridgeDB requests, and
> with phw's help that only took us two days of coding time.)
> 
> It seems to me that adding estimates of version 3 .onion addresses won't
> happen without funding. It's too much work that involves too many people
> that it could be done between funded work.
> 
> At the same time, doing this work seems to be getting more urgent, as
> the version 2 numbers will become less useful over time. If we delay
> this too much, we'll end up having no useful numbers on onion services
> anymore.

Yes true. And the removal of 029 from the network will allow us to start the
deprecation path of v2. It is a long road but once it starts, the train won't
be stoppable :).

Cheers!
David

-- 
AOrq46damX3clZogjR9FlXTru90GV9IT5Rq/J0EzVSA=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20191219/29b05409/attachment.sig>