On Sat, 26 May 2018, Christian Weisgerber wrote:> On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: > > > The defaults for HostKeyAlgorithms option are: [...] > > Why does OpenSSH prefer older and less secure > > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > > I asked Markus and Damien about this in the past but honestly don't > remember the answer. Some of the potential reasons (lack of > standardization, no DNS fingerprint, ...) seem to no longer apply. > I've been wanting to hassle Markus and Damien about this again, > once I run into them in person, but that opportunity hasn't presented > itself yet.Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html Christian is right about our reasoning for the other choices. -d
I don't think we should wait for a RFC in order to use stronger crypto. We already prefer Curve25519 for key exchange without waiting for it. So why wait for a RFC in this case? On Sun, May 27, 2018 at 5:09 AM, Damien Miller <djm at mindrot.org> wrote:> On Sat, 26 May 2018, Christian Weisgerber wrote: > >> On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: >> >> > The defaults for HostKeyAlgorithms option are: [...] >> > Why does OpenSSH prefer older and less secure >> > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? >> >> I asked Markus and Damien about this in the past but honestly don't >> remember the answer. Some of the potential reasons (lack of >> standardization, no DNS fingerprint, ...) seem to no longer apply. >> I've been wanting to hassle Markus and Damien about this again, >> once I run into them in person, but that opportunity hasn't presented >> itself yet. > > Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at > https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html > > Christian is right about our reasoning for the other choices. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
there are more implications to changing key algorithms than KEX algorithms. If a change is made to the specification, then it might invalidate all the keys that are out there, this isn't the case with any other negotiated algorithm, On Sun, 27 May 2018, Yegor Ievlev wrote:> I don't think we should wait for a RFC in order to use stronger > crypto. We already prefer Curve25519 for key exchange without waiting > for it. So why wait for a RFC in this case? > > On Sun, May 27, 2018 at 5:09 AM, Damien Miller <djm at mindrot.org> wrote: > > On Sat, 26 May 2018, Christian Weisgerber wrote: > > > >> On 2018-05-25, Yegor Ievlev <koops1997 at gmail.com> wrote: > >> > >> > The defaults for HostKeyAlgorithms option are: [...] > >> > Why does OpenSSH prefer older and less secure > >> > (https://safecurves.cr.yp.to/) ECDSA with NIST curves over Ed25519? > >> > >> I asked Markus and Damien about this in the past but honestly don't > >> remember the answer. Some of the potential reasons (lack of > >> standardization, no DNS fingerprint, ...) seem to no longer apply. > >> I've been wanting to hassle Markus and Damien about this again, > >> once I run into them in person, but that opportunity hasn't presented > >> itself yet. > > > > Yeah, there's no RFC for ed25519 keys yet. There's an I-D in progress at > > https://tools.ietf.org/id/draft-ietf-curdle-ssh-ed25519-01.html > > > > Christian is right about our reasoning for the other choices. > > > > -d > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >