On 14 Sep 2015, at 09:07, Mike Perry mikeperry@torproject.org wrote:
...
- Security concerns and mitigations
4.1. Mitigating fingerprinting of new HS circuits
By pinning the middle nodes of rendezvous circuits, we make it easier for all hops of the circuit to detect that they are part of a special hidden service circuit with varying degrees of certainty.
...
The most serious of these is the Guard fingerprinting issue. When proposal xxx-padding-negotiation is implemented, services that enable this feature should use those padding primitives to create fake circuits to random middle nodes that are not their guards, in an attempt to look more like a client.
How will this interact with the rate limiting in xxx-padding-negotiation section 4.1?
On 12 Sep 2015, at 10:34, Mike Perry mikeperry@torproject.org wrote:
4.1. Rate limiting
...
We recommend that three consensus parameters be used in the event that the network is being overloaded from padding to such a degree that padding requests should be ignored:
- CircuitPaddingMaxRatio
- The maximum ratio of padding traffic to non-padding traffic (expressed as a percent) to allow on a circuit before ceasing to pad. Ex: 75 means 75 padding packets for every 100 non-padding packets.
- Default: 100
- CircuitPaddingLimitCount
- The number of padding cells that must be transmitted before the ratio limit is applied.
- Default: 500
- CircuitPaddingLimitTime
- The time period in seconds over which to count padding cells for application of the ratio limit.
- Default: 60
XXX: Should we cap padding at these rates, or fully disable it once they're crossed?
If the rate limiting is being applied, that will limit fake middle circuits (with few non-padding packets) to ~500 cells per minute (~4KBytes per second).
Does CircuitPaddingLimitCount reset after CircuitPaddingLimitTime? (I can’t tell from the proposal, but I assume it has to reset, otherwise the limit is quite low, at 500 cells per fake circuit for its entire lifetime [plus whatever dribble it gets from non-padding cells].)
Are those consensus parameters intended to be always set, or just set when there is an issue with padding? (I can see arguments both ways, but having them always set could be useful as a precaution against a quick attack.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)