On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sat, 2020-10-03 at 19:44 +1000, Damien Miller wrote: > > Otherwise, feel free to ask me anything. > > Was it ever considered that the feature itself could be problematic, > security-wise? Of course we considered this. > I see at least two candidates: > - It's IMO generally a bad idea to distribute "better/newer" keys over > a potentially already weaker trust path (i.e. something secured by the > old key). This is strictly no worse than continuing to use the old key, so I don't consider it a problem. > - If some key was compromised (and thus the server itself) an attacker > might use the feature to distribute his own keys, which, during clean > up from the attack, might be overseen. How is this different to the status quo? If you don't clean up keys after a compromise then you have a problem. Anyone doing this already has to be prepared to deal with multiple keys being known for a host. The tooling support for doing this (ssh-keygen -R) works identically regardless of the number of keys. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
