[tor-bugs] #26768 [Core Tor/Tor]: Support onionbalance in HSv3

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#26768: Support onionbalance in HSv3
------------------------------+-----------------------------------------
     Reporter:  asn           |      Owner:  (none)
         Type:  defect        |     Status:  new
     Priority:  Medium        |  Milestone:  Tor: unspecified
    Component:  Core Tor/Tor  |    Version:
     Severity:  Normal        |   Keywords:  tor-hs scaling onionbalance
Actual Points:                |  Parent ID:
       Points:                |   Reviewer:
      Sponsor:                |
------------------------------+-----------------------------------------
 HSv3 need some mods to support the onionbalance design.

 That's because of the cross-certs of the intro key in the descriptor (with
 the desc signing key). Which means that the onionbalance node would need
 to know the intro privkey to be able to complete the cross-cert with its
 own descriptor signing key.

 Here is an approach to route around this with v3 coming from the Seattle
 hackfest:

 {{{
 The descriptor-signing private key for each day is generated based on a
 hash of a shared secret that is shared between the onion service
 controller and the onion service instances.  This way, the instances know
 what the signing key for each day will be.  [Because this is a signing
 key, forward secrecy is not endangered.]

 When uploading descriptors, the instances generate "bogus" descriptors
 (associated with different identity keys) containing intro points and keys
 generated in a way suitable for including in the combined service's onion
 descriptor.  They cross-certify the master signing key, not their own
 descriptors' signing keys.  They upload these descriptors to the hash
 ring.  They look normal to the hash ring directory servers, since only the
 encrypted parts are weird.

 To generate the combined descriptors, the service controller periodically
 downloads all the "bogus" descriptors above, and stuffs their contents
 into a combined descriptor.

 Since the shared secret produces the descriptor keys, the instances can
 also produce descriptors with the valid descriptor signing key generated
 from the shared secret.

 Instances can optionally use client authentication.
 }}}

 This is quite a bit of mods to support onionbalance, but it does seem like
 a plausible approach.

 We should investigate more and move forward here!

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs