Revise initial descriptor upload behavior for onion services

According to rend-spec.txt:

   When uploading descriptors, the hidden service needs to make sure that
   descriptors for different clients are not uploaded at the same time (cf.
   Section 1.1) which is also a limiting factor for the number of clients.

At the moment it's unclear how it should be implemented and why.

• What is the threat model here?
• How exactly descriptors should be uploaded?
• In what range delays should be set?
• How this will work along with absent delays after #20082 (moved)?

changed milestone to %Tor: 0.3.2.x-final

added component::core tor/tor milestone::Tor: 0.3.2.x-final owner::dgoulet parent::20657 points::0.5 priority::very high prop224 research resolution::fixed severity::normal sponsor::R-can status::closed tor-hs tor-spec type::enhancement labels

Trac:
Keywords: N/A deleted, research added

Would be good also to extend this analysis to next generation HS (prop224) as it will become important to figure out the behavior we want before deployment.

Trac:
Milestone: N/A to Tor: 0.2.???
Keywords: N/A deleted, prop224, tor-spec added

Milestone renamed

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.???

Move the 0.3.??? prop224 tickets to the 031 milestone.

Trac:
Milestone: Tor: 0.3.??? to Tor: 0.3.1.x-final

Trac:
Owner: N/A to dgoulet
Status: new to assigned

Trac:
Parent: N/A to #20657 (moved)

Prioritize prop224 tickets for 031 milestone. They are all "Enhancement".

Trac:
Type: task to enhancement
Priority: Medium to Very High

Trac:
Points: N/A to 0.5

Trac:
Sponsor: N/A to SponsorR-can

prop224 tickets going in 032 for early merge. Decided after Amsterdam meeting.

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: 0.3.2.x-final

Current state of prop224 hidden service about descriptor upload.

Service upload their descriptors (current and next for the overlap period) with:

#define HS_SERVICE_NEXT_UPLOAD_TIME_MIN (60 * 60)
#define HS_SERVICE_NEXT_UPLOAD_TIME_MAX (120 * 60)
  desc->next_upload_time =
    (time(NULL) + crypto_rand_int_range(HS_SERVICE_NEXT_UPLOAD_TIME_MIN,
                                        HS_SERVICE_NEXT_UPLOAD_TIME_MAX));

Trying to answer the original questions of this ticket:

What is the threat model here?

As a network observer or Guard of a tor with multiple hidden services, not uploading them at the same time can help hide the fact that A.onion and B.onion aren't necessarily on the same tor instance. Not perfect of course but it helps.

How exactly descriptors should be uploaded?

I assume at least at a random interval that is inside the lifetime of the descriptor on the HSDir side which is 3 hours right now by default with prop224.

In what range delays should be set?

The above I think answers it.

How this will work along with absent delays after #20082 (moved)?

At startup, the service establishes intro points and once they are set for a descriptor, it's immediately uploaded. So at startup, for reachability reasons, we upload as soon as we can. Adding any kind of random delay here could be really annoying for users and application type like Ricochet for instance.

That being said, I'm closing the ticket so we can move on BUT if anything could be improved here or needs more clarification, I suggest we go through tor-dev@ for a discussion and then we can either patch the code or/and the spec according to the conclusions.

Trac:
Status: assigned to closed
Resolution: N/A to fixed

closed

changed time estimate to 4h

moved to tpo/core/tor#20524 (closed)