UpdateHostkeys now enabled by default

[Peter Stuge]

Damien Miller wrote:
> > Was it ever considered that the feature itself could be problematic,
> > security-wise?
> 
> Of course we considered this.

I'm intuitively opposed to fully automating 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.

I disagree. The problem is not with the crypto; I agree that if just
looking at keys without context then a pushed key is no worse than
the key which authenticated the push.

However! Those pushed keys were pushed for some reason, but only the
server knows why; the client can't *know* that reason without some OOB
communication, so must simply /assume/ that the new key is better/preferable.
I consider that dangerous, because it's an assumption and because we
are trained to make this particular assumption too often already.

Also, I believe that this is the first time that servers are given the
power to remotely manipulate client configuration? I consider that
dangerous as well.

Finally, it's a paradigm shift in host key management on clients, away
from Trust-On-First-Use. This isn't dangerous per se, but I do consider
it quite a drastic change, not to be made lightly at all.


I do not disagree with progressive key management, we clearly need to
roll keys now and then, and I'm also not against some automation, but
I don't think that it should be fully automated.

I even find opt-in too aggressive. I would like this to only occur on
explicit client request.

Host keys are quite stable and I think that's a good thing.


> > - 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.

It's different because enabling this feature by default lets a
malicious server distribute many different keys to every connecting
client.

I think cleaning up such a mess on clients is significantly different
from cleaning up a single well-known and compromised key, even if
tooling exists to make both tasks appear identical.


//Peter