openssh unix dev - Nov 2022 - [patch] ssh-keygen(1): by default generate ed25519 key (instead of rsa)

On Mon, 7 Nov 2022, Darren Tucker wrote:
> On Mon, 7 Nov 2022 at 00:51, Job Snijders <job at openbsd.org> wrote:
> [...]
> > Perhaps now is a good time to make Ed25519 the default when invoking
> > ssh-keygen(1) without arguments?
> 
> I don't think so.  Outside of DSA (which is REQUIRED in RFC4253 but is
> considered weak these days), RSA keys are the most widely supported
> key type and thus most likely to work in any given situation, which
> makes them an appropriate default.  If you know this is not the case
> for your environment, that's what "-t" is for.
I don't mind using defaults to apply a little nudge towards better
algorithms. OpenSSH has supported ed25519 keys for almost a decade,
and RFC 8709 has been a standard for a couple of years.

So I'm cautiously supportive of doing this.

-d

?On 11/6/22, 20:01, "openssh-unix-dev on behalf of Damien Miller"
<openssh-unix-dev-bounces+iain.morgan=nasa.gov at mindrot.org on behalf of
djm at mindrot.org> wrote:

    On Mon, 7 Nov 2022, Darren Tucker wrote:

    > On Mon, 7 Nov 2022 at 00:51, Job Snijders <job at openbsd.org>
wrote:
    > [...]
    > > Perhaps now is a good time to make Ed25519 the default when
invoking
    > > ssh-keygen(1) without arguments?
    > 
    > I don't think so.  Outside of DSA (which is REQUIRED in RFC4253 but
is
    > considered weak these days), RSA keys are the most widely supported
    > key type and thus most likely to work in any given situation, which
    > makes them an appropriate default.  If you know this is not the case
    > for your environment, that's what "-t" is for.

    I don't mind using defaults to apply a little nudge towards better
    algorithms. OpenSSH has supported ed25519 keys for almost a decade,
    and RFC 8709 has been a standard for a couple of years.

    So I'm cautiously supportive of doing this.

This could be an issue for environments which have to comply with FIPS 140-2,
which does not permit ed25519.  In such environments, using -t with ssh-add
would work on a per-user basis, but users are so used to the current behaviour
that I suspect it would be rather disruptive.

Having said that, by the time such environments move to a version of OpenSSH
which implements this proposed change, FIPS 140-3 validated cryptographic
modules will hopefully be in place.  I haven't looked over FIPS 140-3, but I
recall seeing something that indicated ed25519 might be permitted under it.  If
that is true, and various requirements get updated to reflect that, it could be
a non-issue.

-- 
Iain

For what it's worth, the current RSA default is FIPS compliant. Although
NIST included ed25519 in FIPS 186-5 and the public comment period closed
more than two years ago, it's still in draft; 186-4 does not include
ed25519 (it does include ecdsa though, with the curves that OpenSSH already
supports).


Tom.III


On Sun, Nov 6, 2022 at 8:04 PM Damien Miller <djm at mindrot.org> wrote:
> On Mon, 7 Nov 2022, Darren Tucker wrote:
>
> > On Mon, 7 Nov 2022 at 00:51, Job Snijders <job at openbsd.org>
wrote:
> > [...]
> > > Perhaps now is a good time to make Ed25519 the default when
invoking
> > > ssh-keygen(1) without arguments?
> >
> > I don't think so.  Outside of DSA (which is REQUIRED in RFC4253
but is
> > considered weak these days), RSA keys are the most widely supported
> > key type and thus most likely to work in any given situation, which
> > makes them an appropriate default.  If you know this is not the case
> > for your environment, that's what "-t" is for.
>
> I don't mind using defaults to apply a little nudge towards better
> algorithms. OpenSSH has supported ed25519 keys for almost a decade,
> and RFC 8709 has been a standard for a couple of years.
>
> So I'm cautiously supportive of doing this.
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>