[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



#26768: Support onionbalance in HSv3
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  asn
     Type:  defect                               |         Status:
                                                 |  assigned
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-hs scaling onionbalance          |  Actual Points:
  network-team-roadmap-september tor-spec        |
Parent ID:  #29998                               |         Points:  8
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor27-must
-------------------------------------------------+-------------------------
Description changed by asn:

Old description:

> 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!

New description:

 We are implementing onionbalance in v3! This is the master ticket.

 [Description changed to not confuse people with the old design.]

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/26768#comment:21>
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