<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Mike,<div class=""><br class=""></div><div class="">Just a few questions about the proposal, inline below:</div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 12 Sep 2015, at 10:34, Mike Perry <<a href="mailto:mikeperry@torproject.org" class="">mikeperry@torproject.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">Here's a proposal describing some padding negotiation cell primitives that<br class="">should be useful to defend against website traffic fingerprinting, hidden<br class="">service circuit fingerprinting, and probably just about any other traffic<br class="">analysis attack under the sun.<br class=""><br class="">The proposal is in my git remote at:<br class=""><a href="https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-padding-negotiation.txt?h=padding_negotiation" class="">https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx-padding-negotiation.txt?h=padding_negotiation</a><br class=""><br class="">==============================<br class=""><br class="">Filename: xxx-padding-negotiation.txt<br class="">Title: Padding Negotiation<br class="">Authors: Mike Perry<br class="">Created: 01 September 2015<br class="">Status: Draft<br class=""><br class=""><br class="">...<br class=""><br class=""><br class="">3. End-to-end circuit padding<br class=""><br class="">For circuit-level padding, we need two types of additional features: the<br class="">ability to schedule additional incoming cells at one or more fixed<br class="">points in the future, and the ability to schedule a statistical<br class="">distribution of arbitrary padding to overlay on top of non-padding<br class="">traffic (aka "Adaptive Padding").<br class=""><br class="">In both cases, these messages will be sent from clients to middle nodes<br class="">using the "leaky pipe" property of the 'recognized' field of RELAY<br class="">cells, allowing padding to originate from middle nodes on a circuit in a<br class="">way that is not detectable from the Guard node.<br class=""><br class="">This same mechanism can also be used to request padding from the Guard<br class="">node itself, to achieve link-level padding without the additional<br class="">overhead requirements on middle nodes.<br class=""><br class="">3.1. Fixed-schedule padding message (RELAY_COMMAND_PADDING_SCHEDULE)<br class=""><br class="">The fixed schedule padding will be encoded in a<br class="">RELAY_COMMAND_PADDING_SCHEDULE cell. It specifies a set of up to 80<br class="">fixed time points in the future to send cells.<br class=""></div></blockquote><div><br class=""></div><div>Do we want to add a length field, for schedules with less than 80 time points?</div><div>Or is this unnecessary?</div><br class=""><blockquote type="cite" class=""><div class="">XXX: 80 timers is a lot to allow every client to create. We may want to<br class="">have something that checks this structure to ensure it actually<br class="">schedules no more than N in practice, until we figure out how to<br class="">optimize either libevent or timer scheduling/packet delivery. See also<br class="">Section 4.3.<br class=""></div></blockquote><div></div><blockquote type="cite" class=""><div><br class=""></div></blockquote><blockquote type="cite" class=""><div class="">The RELAY_COMMAND_PADDING_SCHEDULE body is specified in Trunnel as<br class="">follows:<br class=""><br class=""> struct relay_padding_schedule {<br class=""> /* Number of microseconds before sending cells (cumulative) */<br class=""> u32 when_send[80];<br class=""><br class=""> /* Number of cells to send at time point sum(when_send[0..i]) */<br class=""> u16 num_cells[80];</div></blockquote><blockquote type="cite" class=""><div class=""><br class=""> /* Adaptivity: If 1, and server-originating cells arrive before the<br class=""> next when_send time, then decrement the next non-zero when_send<br class=""> index, so we don't send a padding cell then, too */<br class=""> u8 adaptive IN [0,1];<br class=""></div></blockquote><div><br class=""></div><div>Is this the definition of “adaptivity" that we want?</div><div><br class=""></div><div>I can see that it works in the scenario where a client wants a minimum of</div><div>X cells delivered at-or-before time T (adaptively), where T is a single schedule</div><div>arbitrarily far in the future.</div><div><br class=""></div><div>But if a client wants a minimum of X cells delivered every T microseconds</div><div>(adaptively), then there’s no way to reliably specify that using this scheme. If</div><div>10*X cells originate at the server due to regular traffic in the first interval, that will</div><div>cause the next 10 intervals to be skipped.</div><div><br class=""></div><div>I can see that the histograms work around this issue by refilling with the original</div><div>figures, but I’m not sure that works for fixed-point padding.</div><br class=""><blockquote type="cite" class=""><div class=""> };<br class=""><br class="">To allow both high-resolution time values, and the ability to specify<br class="">timeout values far in the future, the time values are cumulative. In<br class="">other words, sending a cell with when_send = [MAX_INT, MAX_INT, MAX_INT,<br class="">0...] and num_cells = [0, 0, 100, 0...] would cause the relay to reply<br class="">with 100 cells in 3*MAX_INT microseconds from the receipt of this cell.<br class=""><br class="">3.2. Adaptive Padding message (RELAY_COMMAND_PADDING_ADAPTIVE)<br class=""><br class="">...<br class=""><br class="">3.2.4. Token removal and refill<br class=""><br class="">If the remove_tok field is set to true for a given state's histogram,<br class="">then whenever a padding packet is sent, the corresponding histogram<br class="">bin's token count is decremented by one.<br class=""><br class="">If a packet matching the current state's transition_reschedule_events<br class="">bitmask arrives from the server before the chosen padding timer expires,<br class="">then a token is removed from the nearest non-empty bin corresponding to<br class="">the delay since the last packet was sent, and the padding packet timer<br class="">is re-sampled from the histogram.<br class=""></div></blockquote><div><br class=""></div><div>Does nearest mean “next highest” or “closest”?</div><br class=""><blockquote type="cite" class=""><div class=""><br class="">If the entire histogram becomes empty, it is then refilled to the<br class="">original values.<br class=""><br class="">...</div></blockquote></div><div class=""><br class=""></div><div class="">Thanks</div><div class=""><br class=""></div><div class="">Tim</div><br class=""><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Tim Wilson-Brown (teor)</div><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div style="orphans: auto; text-align: start; text-indent: 0px; widows: auto; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">teor2345 at gmail dot com<br class="">PGP: 968F094B (ABFED1AC & A39A9058 expire 15 Sep 2015)<br class=""><br class="">teor at blah dot im<br class="">OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F (From 1 Sep 2015)</div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div></div>
</div>
<br class=""></div></body></html>