Opened 13 months ago

Last modified 10 days ago

#26768 assigned defect

Support onionbalance in HSv3

Reported by: asn Owned by: asn
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-hs scaling onionbalance network-team-roadmap-september tor-spec
Cc: s7r, gk Actual Points:
Parent ID: #29998 Points: 15
Reviewer: Sponsor: Sponsor27-must

Description (last modified by nickm)

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!

Child Tickets

Attachments (1)

xxx-onionbalance-v3.txt (7.6 KB) - added by nickm 5 months ago.

Download all attachments as: .zip

Change History (16)

comment:1 Changed 13 months ago by nickm

Description: modified (diff)

comment:2 Changed 11 months ago by s7r

Cc: s7r added

comment:3 Changed 9 months ago by asn

Just some notes from a recent discussion about onionbalance vs the current poor man's onionbalance where every node races each other for uploading descriptors:

With the poor man's solution, there are issues when you start removing/rebooting nodes, since if the offline node currently has the active descriptor there will be reachability issues until another node wins the race.

We could fix this by making all nodes upload more frequently, and be able to pause publishes from the rebooting node, and also by ensuring that all clients will re-fetch descriptors smoothly if they can't connect to the intro points.

comment:4 Changed 5 months ago by gk

Cc: gk added

comment:5 Changed 5 months ago by asn

Sponsor: Sponsor27-must

comment:6 Changed 5 months ago by asn

Points: 20

comment:7 Changed 5 months ago by pili

Parent ID: #29998

comment:8 Changed 5 months ago by nickm

A big choice to make here will be whether to fix #29583 or not. I think we should fix #29583, but to do so will create some compatibility issues that we'll need to navigate.

If we don't fix #29583, this ticket is easier. If we do fix it, we'll need additional machinery to make onionbalance possible on v3 descriptors. I'm attaching a draft proposal I wrote a while ago about how to make that work; we should turn it into a real proposal if we decide to fix #29583.

Changed 5 months ago by nickm

Attachment: xxx-onionbalance-v3.txt added

comment:9 Changed 4 months ago by gaba

Keywords: network-team-roadmap-2019-Q1Q2 added

comment:10 Changed 4 weeks ago by gaba

Keywords: network-team-roadmap-september added; network-team-roadmap-2019-Q1Q2 removed

comment:11 Changed 3 weeks ago by dgoulet

Keywords: tor-spec added

I've taken nickm's draft and cleaned it up as an official draft: prop306.

https://lists.torproject.org/pipermail/tor-dev/2019-July/013942.html

For merge, see my torspec.git branch: ticket26768_01

At this point, we'll proceed with the easy approach for OnionBalance v3 that is not fixing #29583 just now but still having prop306 in the backlog.

comment:12 Changed 3 weeks ago by dgoulet

Owner: set to asn
Status: newassigned

comment:13 Changed 3 weeks ago by dgoulet

Points: 2015

Points changed at the Stockholm meeting.

comment:14 Changed 10 days ago by asn

Opened ticket about v3 descriptor support for stem: https://trac.torproject.org/projects/tor/ticket/31369#ticket

Still need to figure out how the blinded key generation is gonna work in Python since that's needed for HSPOST.

comment:15 in reply to:  14 Changed 10 days ago by teor

Replying to asn:

Opened ticket about v3 descriptor support for stem: https://trac.torproject.org/projects/tor/ticket/31369#ticket

Still need to figure out how the blinded key generation is gonna work in Python since that's needed for HSPOST.

We could start with the reference implementation from the tests?
https://gitweb.torproject.org/tor.git/tree/src/test/ed25519_exts_ref.py#n34

Note: See TracTickets for help on using tickets.