-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09/01/15 14:40, Yawning Angel wrote:
I believe most of BuFLO's shortcomings documented in Cai, X., Nithyanand, R., Johnson R., "New Approaches to Website Fingerprinting Defenses" 5.A. apply to the currently proposed defense, though some of the problems have been solved via CS-BuFLO/Basket.
Thanks for the pointer to an excellent paper. The single-hop padding scheme I suggested is closer to CS-BuFLO than BuFLO: it operates over TCP, doesn't inject padding when the TCP connection is congested, and allows the initiator to decide when to close each hop of the circuit (similar to CS-BuFLO's early termination).
CS-BuFLO as implemented in Basket without application assistance (to terminate padding early) has an absolutely gargantuan amount of bandwidth overhead, and the smarter Basket variant that doesn't have stupid amounts of sender side buffering isn't portable (for the same reasons that the new KIST code isn't).
Why do you need stupid amounts of buffering? Bursts of data from the application can be smoothed out by keeping a small buffer and making the application block until there's space in the buffer - as TCP does, for example.
In general I don't see any need for a padding scheme to touch anything below the TLS layer, or buffer any more data at the endpoints or relays than is already buffered.
None of the schemes I've seen proposed so far fit well into Tor as it is now, due to the fact that multiple circuits are multiplexed over a single channel (that enforces in-order-reliable delivery semantics). HOL blocking is a thing that needs to be considered. Solving this undoubtedly has really interesting anonymity impacts that I haven't given much thought to.
I don't see why padding needs to make multiplexing more complicated. We already have logic for multiplexing circuits over a TLS connection. Padding cells don't behave any differently from data cells in terms of head-of-line blocking.
Another issue with all of the padding schemes that I currently don't have a solid suggestion for is how to actually detect malicious peers that don't pad/pad incorrectly.
Is it necessary to detect peers that aren't padding correctly? In adaptive padding, if a relay detects a gap in the incoming traffic along a circuit, it doesn't try to assign blame for the existence of the gap - it just fills it. Likewise for the single-hop padding scheme I suggested: each relay is responsible for normalising its output, not speculating about why its input was or wasn't normalised.
Cheers, Michael