It is redundant thanks to Kloak and there is reason to believe its packet generation frequency (50Hz) is probably too fine grained allowing for CPU activity side-channel leaks. Something we could do without since we are in the business of sanitizing protocols to mitigate timing leaks.
We don’t ship any SSH config files at time of writing. Never did. Doing so would be dangerous because it could break existing SSH setups, lockout people from servers. Next best thing would be offering an op-in config package for installation.
And SSH doesn’t have a .d config snippet drop-in folder.
IIRC what Vinnie described, this introduces a side-channel or even covert channel in the SSH protocol that is similar to the one described in the “hot or not” clock skew paper for TCP, that we spent a lot of effort tearing out by disabling timestamps and rewriting ISNs for.
Well this is awful. We will have no choice but to talk to upstream about it.
The high grained frequency it generates packets constantly at could potentially reveal changes in CPU load of the system, leaking info by an adversary who induces CPU load on an onion service - leading to deanonymization. Also can leak info about encryption keys/operations running on a CPU observable on the network
If you believe ssh wanted to introduce a security feature but actually could have introduced a CPU activity side-channel leak please report this to SSH.