UpdateHostkeys now enabled by default

[Damien Miller]

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