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
