[tor-bugs] #32604 [Core Tor/Tor]: Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID directive

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Dec 6 01:40:05 UTC 2019


#32604: Add HiddenServiceExportRendPoint and HiddenServiceExportInstanceID
directive
-----------------------------------------+---------------------------------
 Reporter:  moonsikpark                  |          Owner:  (none)
     Type:  enhancement                  |         Status:  needs_revision
 Priority:  Medium                       |      Milestone:  Tor:
                                         |  0.4.3.x-final
Component:  Core Tor/Tor                 |        Version:
 Severity:  Normal                       |     Resolution:
 Keywords:  tor-hs tor-dos extra-review  |  Actual Points:
Parent ID:  #32511                       |         Points:
 Reviewer:  dgoulet, ahf, teor           |        Sponsor:  Sponsor27-can
-----------------------------------------+---------------------------------

Comment (by moonsikpark):

 Replying to [comment:22 teor]:
 > No, I don't think we should export raw cryptographic material. If you
 really want this info, you should export
 `siphash(circ->hs_ident->rendezvous_cookie)`. (The cookie should not be
 common across instances, unless the client is doing a replay attack across
 different instances. If you want to be able to detect relay attacks, you
 should do `H(CONSTANT_PREFIX|circ->hs_ident->rendezvous_cookie)`.)
 I agree. Should we have a new variable that stores
 `H(CONSTANT_PREFIX|circ->hs_ident->rendezvous_cookie)` in `rend_data_t`?
 > I'm going to suggest a way forward:
 > 1. We decide what to do about the existing broken fields:
 https://trac.torproject.org/projects/tor/ticket/32604?replyto=21#comment:19
 > 2. We do a design for the final set of fields.
 > 3. We land this patch with the current fields, in the positions they
 will have in the final design.
 > 4. We open a new ticket for any new fields.
 >
 > This feature is getting complex enough that we might need a proposal, a
 spec, or a very well-designed manual page entry.
 While I agree on most parts, I fear that we might have to introduce
 breaking changes twice or more. Maybe landing all at the same time is the
 way to go?

 I think writing a proposal or a spec is the way to go considering the
 complexity. How do I write a proposal or a spec?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32604#comment:23>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list