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

[Tim Wilson-Brown - teor]

> On 14 Sep 2015, at 09:07, Mike Perry <mikeperry at torproject.org> 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 at 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)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150914/202f5d87/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150914/202f5d87/attachment-0001.sig>