We had our meeting about the netflow padding defense proposal and implementation today: https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-padding... Here's the IRC logs: http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-22-16.00.log.html The minutes+action item summary is as follows: - Write a torspec branch to describe the defense and changes since the proposal. The protocol changes will go in tor-spec.txt, and the behavior/usage will go in padding-spec.txt. Right now, I do not plan to also update Prop#251 itself, as the spec will be canonical. - In padding-spec.txt, we need to describe the options for disabling padding, reducing padding, and connection lifespan controls as these have changed since Prop#251 was written. - We are not going to use channel padding to obscure circuit setup (https://trac.torproject.org/projects/tor/ticket/17591), as fingerprinting is more of a risk from the guard node rather than someone watching TLS. It is better handled through multi-hop padding. That ticket needs to be closed or replaced with one to write a separate proposal for multi-hop padding. - We discussed overhead bounds and if we believe there are adversaries that exist that this will protect against (who won't/aren't doing full take for example). We believe data retention regulation and ISP practices strongly indicates that there are. - Bridges will be padded like clients are. - We discussed using behavioral checks to differentiate clients from relays instead of the consensus checks. I do not like this option, as it introduces protocol side effects that seem sloppy and prone to cause problems in the future (like CREATE_FAST did). I am not sure if we came to an agreement here. - We need to be sure to describe the protocol negotiation and forward compatibility properties of the padding negotiation in detail in tor-spec.txt. After the meeting, Nick and I discussed some implementation details. We need to improve the callback handling and maybe also upgrade libevent's timer algorithm. Nick is working on a new data structure to look up channels in O(1), so we can fix a callback channel dropping bug he spotted in code review, and eliminate the need to reach into channeltls_t from channelpadding.c. Nick also has code review comments in https://trac.torproject.org/projects/tor/ticket/16861#comment:39 that I have mostly fixed, minus the callback issue. I will be posting a reply and a new branch later today. I think that's it. Please reply with questions, comments, or additions, or if I missed anything. -- Mike Perry