Future deprecation of ssh-rsa

[Damien Miller]

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