Mailing List Archive

Future deprecation of ssh-rsa
For the last few releases, there has been a notice that ssh-rsa will be deprecated in a near-future release. Is there a target release for this deprecation to take effect? I saw in the 8.4 release notes that UpdateHostKeys is going to be default enabled in the next release to prepare for this. Is it likely that 8.6 will deprecate ssh-rsa after a release cycle of UpdateHostKeys being default or are we likely talking further in the future than that?

I apologize if this has been asked before and I've missed it. I've tried reading threads that looked relevant and did not see the answer.


Thanks,
Alex
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
Alex,

Because you ask about UpdateHostKeys I think there might be a common
misunderstanding behind your post. Apologies if I assumed wrongly!

RSA keys are not going away, and will continue to be supported.

'ssh-rsa' is the prefix used for the public keys as stored on disk,
but that on-disk key format is not what's being deprecated.

While this isn't obvious to those who aren't well-versed in SSH wire
protocol internals, in the context of the deprecation, 'ssh-rsa'
refers only to the ephemeral, over-the-wire signature algorithm used
to validate the client's possession of the key.

As long as both the client and server support the newer signature
algorithms like 'rsa-sha2-256' or 'rsa-sha2-512', your RSA keys will
continue to work. (Also, the 'ssh-rsa' prefix is still used for the
key, even though the signature algorithm is now named differently.)

The necessary signature algorithm support was added in OpenSSH 7.2.

I hope this helps,

--
Chris Danis (he/him)
Staff Site Reliability Engineer
Wikimedia Foundation
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
Chris,
Thanks for the response! Maybe I shouldn't have mentioned UpdateHostKeys in my post. I only mentioned it because it is referenced in a way that I read as a part of the strategy to deprecate ssh-rsa - in the release notes for 8.4 and in a previous post regarding the deprecation notice: "We're still one or two steps away ATM, e.g. we still need to fix the corner cases in UpdateHostkeys and enable it)". My possibly faulty reading of context there was that these were steps leading up to the deprecation. 


I am perhaps imprecise and mis-communicating my understanding of the deprecation because I don't speak the language of ssh as well as some on here. My understanding, which I think is what you are highlighting in your response is that the deprecation is limited the sha1 based ssh-rsa signature algorithm. I understand rsa-sha2-256 and rsa-sha2-512 to be the sha2 alternatives which are continuing support. I'm sorry if I am still missing what you are saying. I actually rather appreciate the way you described it in a clarity I struggle to boil it down to as I just don't spend enough time in the ssh land(as you rightly surmised).


Thank you,
Alex






On Tuesday, October 20, 2020, 08:25:58 PM EDT, Chris Danis <cdanis@wikimedia.org> wrote:





Alex,


Because you ask about UpdateHostKeys I think there might be a common
misunderstanding behind your post.  Apologies if I assumed wrongly!

RSA keys are not going away, and will continue to be supported.

'ssh-rsa' is the prefix used for the public keys as stored on disk,
but that on-disk key format is not what's being deprecated.

While this isn't obvious to those who aren't well-versed in SSH wire
protocol internals, in the context of the deprecation, 'ssh-rsa'
refers only to the ephemeral, over-the-wire signature algorithm used
to validate the client's possession of the key.

As long as both the client and server support the newer signature
algorithms like 'rsa-sha2-256' or 'rsa-sha2-512', your RSA keys will
continue to work.  (Also, the 'ssh-rsa' prefix is still used for the
key, even though the signature algorithm is now named differently.)

The necessary signature algorithm support was added in OpenSSH 7.2.

I hope this helps,

--
Chris Danis (he/him)
Staff Site Reliability Engineer
Wikimedia Foundation
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
On Wed, 21 Oct 2020, Alex Harrison wrote:

> For the last few releases, there has been a notice that ssh-rsa will
> be deprecated in a near-future release. Is there a target release
> for this deprecation to take effect? I saw in the 8.4 release notes
> that UpdateHostKeys is going to be default enabled in the next release
> to prepare for this. Is it likely that 8.6 will deprecate ssh-rsa
> after a release cycle of UpdateHostKeys being default or are we likely
> talking further in the future than that?
>
> I apologize if this has been asked before and I've missed it. I've
> tried reading threads that looked relevant and did not see the answer.

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.

What we'll probably do is start by turning off ssh-rsa in git HEAD at
after the next release, and leave it off until close to the next release.
This will give people who use OpenSSH HEAD (e.g. the users of OpenBSD
-current) some experience with the practical impact of the change while
we're giving time for UpdateHostKeys to reach a wider population and do
its thing.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
On Wed, 21 Oct 2020, Alex Harrison wrote:

> Chris,
> Thanks for the response! Maybe I shouldn't have mentioned
> UpdateHostKeys in my post. I only mentioned it because it is
> referenced in a way that I read as a part of the strategy to deprecate
> ssh-rsa

Right, it is part of our strategy for addressing host keys as more SSH
server implementations support ECDSA and Ed25519 host keys than support
rsa-sha2-256/512. Gracefully migrating users to other algorithms is an
easy path to avoid RSA/SHA1 (and to generally use better crypto).

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
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.

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*

I don't think that these three cases can reasonably be considered
to ever have the same, or even comparable, security properties. Do you?


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Future deprecation of ssh-rsa [ In reply to ]
On 22.10.20 00:37, Damien Miller wrote:
> 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.

No contest there, but do you mean to say that UpdateHostKeys actually
enforces new algos and keys to be "better" than the currently-used one?
Per what, and whose (client/server), definition?

I guess that Peters mistrust is largely based on that "better, worse,
whatever" smacks of facilitating a downgrade attack, even if we don't
see how one would *actually* succeed *today* ...

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH
Re: Future deprecation of ssh-rsa [ In reply to ]
On Thu, 22 Oct 2020, Jochen Bern wrote:

> On 22.10.20 00:37, Damien Miller wrote:
> > 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.
>
> No contest there, but do you mean to say that UpdateHostKeys actually
> enforces new algos and keys to be "better" than the currently-used one?
> Per what, and whose (client/server), definition?

Per the HostkeyAlgorithms list in the client.

Think of it like this: UpdateHostkeys allows a server to inform the
client of its set of keys. HostkeyAlgorithms (on the client) decides
which the client actually uses.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev