Consider adopting vanguard's security suggestions for onionbalance

changed milestone to %Tor: unspecified in legacy/trac

added component::core tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac onionbalance in Legacy / Trac priority::medium in Legacy / Trac scaling in Legacy / Trac severity::normal in Legacy / Trac sponsor::27-can in Legacy / Trac status::new in Legacy / Trac tor-hs in Legacy / Trac tor-spec in Legacy / Trac type::defect in Legacy / Trac labels

In particular, the most important is property that it should be possible for an onion service to use onionbalance without giving away how many back-end onionbalance instances there are.

Second to that, and ideally, it would be best if it is possible for a service to use onionbalance v3 without it being obvious to clients that the service is using onion balance at all. So the HSv3 descriptor structure should be the same formatting for onionbalamce case as for the vanilla HSv3 case, and not have different orderings, different numbers of IPs, or recognizable signing oddities.

I'm not sure if this is even feasible with whatever cryptographic tricks we're doing to support v3 (I wish I paid more attention when we were brainstorming among options :/), but maybe there is still a way?

After that, the actual vanguards integration and juggling of the state file is just a nice-to-have.

Trac:
Keywords: tor-hs scaling onionbalance network-team-roadmap-september tor-spec deleted, tor-hs scaling onionbalance tor-spec added