> Brian Bennett <[email protected]> wrote: > > Not to get too far off topic, but is there actually any evidence to back > up that statement? I've been searching for a number of years for someone > who can speak intelligently on the topic. As I understand it, statements > like this are parroted simply due to key sizes. While ssh-keygen can only > create DSA keys of 1024 bits, openssl can generate arbitrarily large DSA > keys that can be used with OpenSSH.
From what I understand after reading openssh-unix-dev for the last few years, the biggest issue with DSA for SSH is that the SSH RFC mandates the use of SHA-1 hashes only for DSA keys. At the same time, the NIST spec for DSA mandates that for keys >1024 bits you must not use SHA-1. This is why the OpenSSH keygen utility doesn't allow DSA keys >1024 bits, because using them has to either violate the SSH RFC, or the NIST standards for DSA. The OpenSSH developers see replacing DSA with ECDSA as a way out of this problem, since the spec for ECDSA support includes longer keys and better hashes. Thus they consider support for plain DSA deprecated in favour of moving to ECDSA. So it's not really out of some concern for a specific weakness in DSA itself, but rather a combination of factors: * Their hands are tied with respect to increasing its key size without violating standards, * 1024-bit keys are starting to look a bit weak, and * They have already given people an alternative path forwards (ECDSA) As a result, I don't really consider it a huge security risk to leave DSA support on in our builds by default specifically for backwards-compat, though I acknowledge that in general discouraging the generation of new 1024-bit DSA keys by users is probably wise. Additionally, if we went ahead and shipped a SmartOS image with DSA disabled by default, and our users have DSA keys in their authorized_keys as their only means of remote access to a server, the change would lock them out. In other distros and operating systems, this could be handled with a config migration script of some kind, or a warning before upgrading. However, with the nature of SmartOS as a live distro running from an immutable image, neither of these mechanisms are really established and available. Since the "failure mode" here (locking users out of their server's gz after an upgrade) is not acceptable, and we don't have a good way around it ready to use today, I consider that re-enabling DSA keys is worthwhile, though I am certainly open to re-visiting this decision now and in the future if more information or evidence becomes available. Hope that explanation helps. ------------------------------------------- smartos-discuss Archives: https://www.listbox.com/member/archive/184463/=now RSS Feed: https://www.listbox.com/member/archive/rss/184463/25769125-55cfbc00 Modify Your Subscription: https://www.listbox.com/member/?member_id=25769125&id_secret=25769125-7688e9fb Powered by Listbox: http://www.listbox.com
