openssh unix dev - Oct 2020 - UpdateHostkeys now enabled by default

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

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.

On Sun, 4 Oct 2020 at 14:38, Christoph Anton Mitterer
<calestyo at scientia.net> wrote:
[...]
> 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.
How is that scenario any different from the attacker keeping a copy of
the compromised server's private keys, other than causing more
evidence to be created when the attacker's keys get sent out?

-- 
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

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

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