Opened 3 years ago

Closed 2 years ago

#20524 closed enhancement (fixed)

Revise initial descriptor upload behavior for onion services

Reported by: twim Owned by: dgoulet
Priority: Very High Milestone: Tor: 0.3.2.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs, research, tor-spec, prop224
Cc: Actual Points:
Parent ID: #20657 Points: 0.5
Reviewer: Sponsor: SponsorR-can

Description

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?

Child Tickets

Change History (11)

comment:1 Changed 3 years ago by twim

Keywords: research added

comment:2 Changed 3 years ago by dgoulet

Keywords: tor-spec prop224 added
Milestone: Tor: 0.2.???

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.

comment:3 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:4 Changed 3 years ago by dgoulet

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

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

comment:5 Changed 3 years ago by dgoulet

Owner: set to dgoulet
Status: newassigned

comment:6 Changed 3 years ago by dgoulet

Parent ID: #20657

comment:7 Changed 3 years ago by dgoulet

Priority: MediumVery High
Type: taskenhancement

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

comment:8 Changed 3 years ago by dgoulet

Points: 0.5

comment:9 Changed 3 years ago by dgoulet

Sponsor: SponsorR-can

comment:10 Changed 2 years ago by dgoulet

Milestone: Tor: 0.3.1.x-finalTor: 0.3.2.x-final

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

comment:11 Changed 2 years ago by dgoulet

Resolution: fixed
Status: assignedclosed

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?

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.

Note: See TracTickets for help on using tickets.