[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #30172 [Core Tor/Tor]: Always send PADDING_NEGOTIATE if middle supports it

#30172: Always send PADDING_NEGOTIATE if middle supports it
-------------------------------------------------+-------------------------
 Reporter:  mikeperry                            |          Owner:  (none)
     Type:  enhancement                          |         Status:  new
 Priority:  Medium                               |      Milestone:
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,        |  Actual Points:
  padding, 041-proposed                          |
Parent ID:  #28634                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor2-can
-------------------------------------------------+-------------------------
Description changed by mikeperry:

Old description:

> We should define some kind of NULL machine for whatever hop is most
> common in our padding machine list, and always negotiate that machine.
>
> Similarly, this NULL machine should (maybe) set should_negotiate_end and
> send a PADDING_NEGOTIATE at circuit close.
>
> We need to do this so that there isn't an obvious PADDING_NEGOTIATE cell
> request/response pair with obvious timings that it went to the middle
> node (ie the response will come faster than all other responses on the
> circuit). See also #30092 for similar motivating reasoning.

New description:

 We should define some kind of NULL machine for whatever hop is most common
 in our padding machine list, and negotiate that machine if no other
 machines apply to the current circuit. This machine shouldn't take up a
 slot or count as negotiated, tho, so we can still negotiate other machines
 if need be..

 Similarly, this NULL machine should (maybe) set should_negotiate_end and
 send a PADDING_NEGOTIATE at circuit close.

 We need to do this so that there isn't an obvious PADDING_NEGOTIATE cell
 request/response pair with obvious timings that it went to the middle node
 (since the PADDING_NEGOTIATED response will come faster than all other
 responses on the circuit). See also #30092 for similar motivating
 reasoning.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30172#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs