[tor-dev] Proposal 251 (netflow padding) meeting logs, minutes, and action items

[Mike Perry]

We had our meeting about the netflow padding defense proposal and
implementation today:
https://gitweb.torproject.org/torspec.git/tree/proposals/251-netflow-padding.txt

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160122/35671ca8/attachment.sig>