On Wed, 21 Oct 2020, Peter Stuge wrote: > I've expressed several concerns with enabling UpdateHostKeys by default, > none of which were even commented on, so this topic seems to not be in > any way open for discussion, but I'll still add one more thing here. I saw your last message, but it seemed to be a general statement of disagreement with the idea rather than anything concrete that I could respond to. It is not true to say that it is not open for discussion, even a cursory search of the mailing list archives will demonstrate this. > Peter Stuge wrote: > > Subject: Re: UpdateHostkeys now enabled by default > > Date: Mon, 5 Oct 2020 11:22:29 +0000 > .. > > 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. > .. > > Host keys are quite stable and I think that's a good thing. > > > Damien Miller wrote: > > No, we haven't set a target date yet. It really depends on how well > > turning on UpdateHostKeys goes, how quickly a release with UpdateHostKeys > > ends up on common OS distributions and a couple of other things. > > Beyond strongly disagreeing with clients silently accepting and persisting > unsolicited configuration changes from servers by default, I would like to > see differentiation between a couple of different UpdateHostKeys cases: > > * from ssh-rsa to rsa-sha2-* without the host key changing > * from ssh-rsa to either ssh-rsa or rsa-sha2-* with a *new host key*, and > * from ssh-rsa to say ssh-ed25519 with a *new public host key algorithm* The first case doesn't relate to UpdateHostKeys at all. rsa-sha2-* is a signature type, not a key type. The second case is a case of server host key rotation, which becomes possible for the first time using UpdateHostKeys. The third case is an example of a client learning a new host key type via UpdateHostKeys. It will be preferred if the client's setting for HostkeyAlgorithms prefers it, which it will by default. > I don't think that these three cases can reasonably be considered > to ever have the same, or even comparable, security properties. Do you? Well, they are three different things of which only two relate to UpdateHostKeys. What's your point? The abilility to gracefully rotate persistent keys is a fundamental capability in a cryptosystem. Being able to migrate to better algorithms over time without breaking continuity of trust is a related capability. Both these are IMO serious omissions from the SSH standards. Not having these capabilities meant that servers used DSA longer than they should have, used RSA/1024 when they should have moved to longer key lengths and could not adopt better signature algorithms like Ed25519 when they became available. -d _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
