Re: [tor-dev] Proposal 247 (Hidden Service Vanguards) Overhaul and Proposal: Padding Negotiation

[Tim Wilson-Brown - teor <teor2345@xxxxxxxxx>]

On 14 Sep 2015, at 09:07, Mike Perry <mikeperry@xxxxxxxxxxxxxx> wrote:

...


4. 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@xxxxxxxxxxxxxx> 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)

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev