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