Always send PADDING_NEGOTIATE if middle supports it

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 at later points if the circuit purpose changes, etc.

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 legacy/trac#30092 (moved) for similar motivating reasoning.

changed milestone to %Tor: unspecified in legacy/trac

added circpad-researchers-maybe-want in Legacy / Trac component::core tor/tor in Legacy / Trac milestone::Tor: unspecified in Legacy / Trac padding in Legacy / Trac points::4 in Legacy / Trac priority::medium in Legacy / Trac severity::normal in Legacy / Trac sponsor::2-can in Legacy / Trac status::new in Legacy / Trac tor-cell in Legacy / Trac tor-relay in Legacy / Trac type::enhancement in Legacy / Trac wtf-pad in Legacy / Trac labels

Trac:
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 legacy/trac#30092 (moved) for similar motivating reasoning.

to

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 legacy/trac#30092 (moved) for similar motivating reasoning.

Trac:
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 legacy/trac#30092 (moved) for similar motivating reasoning.

to

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 at later points if the circuit purpose changes, etc.

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 legacy/trac#30092 (moved) for similar motivating reasoning.

Tentatively calling this unspecified, but the 041-proposed can move it forward.

Trac:
Milestone: N/A to Tor: unspecified

While this is simple to implement, figuring out exactly which strategy to use will take some experimentation.

Trac:
Points: N/A to 4

Taking this out of 041-proposed. See also legacy/trac#30348 (moved). We should think about this more and maybe wait a full research cycle before doing this.

Trac:
Parent: legacy/trac#28634 (moved) to N/A
Keywords: 041-proposed deleted, N/A added

Trac:
Keywords: N/A deleted, circpad-researchers-maybe-want added

changed time estimate to 32h

mentioned in issue legacy/trac#30348 (moved)

moved from legacy/trac#30172 (moved)

added Feature label and removed 1 deleted label

added Padding Padding Research Relay labels and removed 1 deleted label

added Proposal Ideas label

removed milestone

closed

moved to torspec#122