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. > 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. Same scenario obviously if the compromise is never detected but just used to get keys for MitM servers to clients... and afterwards removing any trace/backdoor from the server. Cheers, Chris. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
