Re: UpdateHostkeys now enabled by default

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux