On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote: > On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote: > > This is strictly no worse than continuing to use the old key, so I > > don't consider it a problem. > > Well but in reality it will lead to people never again replace their > key by proper means. Well, first I disagree that this method is improper. The existence of UpdateHostkeys doesn't stop people hard-rotating their keys if that's what they prefer. > > 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. > > Well the big difference is IMO: AFIAU this feature distributes the > newer server keys to clients right? > > So even if the compromise is detected on the server side (and > properly cleaned up) the may be countless of clients (which you > can never reach all) who still have the compromised keys and may > subsequently be vulnerable to MitM, since they'd still trust that the > key authenticates server foo.bar. Again, how is this different to the status quo? If a server has been compromised then its host key(s) should be considered compromised too and should be cleaned up. This is true regardless of the existence of UpdateHostkeys. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
