Consider reducing the range of sendme_inc negotiation
In congestion control, because endpoints must agree on sendme_inc, and because the consensus may not be in sync between endpoints, we have the exit or onion service control the sendme_inc, which the client validates by ensuring it is within a factor of 2X of the consensus value it sees.
It may be the case that a traffic analysis side channel could be built from this 2X range that allows Exits or onion services to segment clients into buckets using this 2X range, and then Guard relays could detect this rate of sendme by guessing it due to the rate of packets in the return direction during a download. It is debatable how serious this side channel is, because without padding and drop cell protection, there are many many more traffic analysis side channels in Tor are far more severe.
The good news is that it trivial to reduce this range of validation at any point, in a future release. We simply change congestion_control_validate_sendme_increment()
to only allow +/- 1 instead of 2X. This does not impact negotiation ability, because all it changes is the dirauth policy with respect to updating sendme_inc to only change it by +/-1 every 3-4 hours.
From extensive Shadow simulation, we have fairly high confidence that sendme_inc needs to be 31-32 cells. The only reason to keep this range at 2X is in case Shadow is mis-calibrated from live in some way, and we may discover that due to this, we need a larger range over which to change sendme_inc. Otherwise the validation could be +/- 1 or 2, instead of 2X.
Still, given that there are worse side channels currently in Tor, at least for now, we should retain the flexibility to alter sendme_inc by wider margins, until we have more confidence in Shadow simulation (by observing that live behaves as Shadow has predicted it will).