Our session on Friday about Hidden Service Fingerprinting wandered a lot. Ultimately, we concluded that it will be hard to fully defend against this attack without a more formally specified state machine that describes hidden service circuit usage fully. However, we may still be able to extend the Netflow Padding defense to pad more often during circuit setup, which should at least improve the situation against an adversary that is externally monitoring the Guard node. Here's the specific action items from the session yesterday: * Review Prop 224 and other proposals for distinguishes for client traffic * Specify a protocol state machine as part of the design * If it is more complicated than the TCP state machine, we should run in fear * Otherwise, researchers should be able to make use of this state machine to determine optimal padding * Netflow padding should have a state to cover circuit setup * Based on Circuit Build Timeout * This allows only 2-10 seconds or so of more frequent padding * The "HS's sometimes need to use a second Guard" distinguisher * The RP should never be a Guard node * The third level node should never be a Guard node * TBB Update pings over HS * Increases the Base Rate, since more clients are building hidden service circuits * This is far easier to do for the Torbutton RecommendedTBBVersions fetch since the updater has special cert pinning that would need to be altered for hidden services * Future Research: * Conflux + Guard Sets * Provides Redundancy against active delay and DoS attacks * May help against fingerprinting and correlation * However, still won't help against a datacenter adversary :/ -- Mike Perry