Objective 1, Activity 2: Denial of service defences
This is the parent ticket to hold any tickets under this activity, including:
- Reducing the amount of circuits that they build over time on the Tor network
- Providing more ways for onion service administrators to control the influx of incoming users in heavy traffic scenarios.
- Improving our defense mechanisms by:
- Decreasing onion service load on the Tor network, by slowing down Tor circuit creation on startup.
- Optimizing relevant onion service functions that are called multiple times therefore taking a lot of the CPU.
- Making it harder for adversaries to force services to rotate their introduction points.
- Writing a Tor software change proposal for a “rendezvous approver” API that can be useful for:
- Rate limiting; allow at most N unauthenticated clients over a set time period
- Extra-conservative logic like "stop accepting connections during potential guard discovery"
- Limiting capacity to control server load; only allow N simultaneous clients.
- Protocol-tuned rules for things like Ricochet
- More advanced pre-rendezvous authorization
- Load-balancing across multiple servers running Tor onion services
- Closing client circuit once the INTRO1/ACK dance has been completed, decreasing load on the Tor network.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information