On Fri, 29 Dec 2017, Daniel Kahn Gillmor wrote:> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: > > Why not make minimum key length a tunable, just as the other options are? > > Because the goal of building secure software is to make it easy to > answer the question "are you using it securely?"This is a nice summation of our approach. It's the same reason we've never implemented the null cipher and also one of the reasons we removed SSHv1. We try to balance compatibility with avoiding danger. This is why it's still possible to explicitly enable (weak, but AFAIK not broken) DSA keys if you need them, but RSA768 has actually been demonstrated to be broken with an academic team factoring a key back in 2009 at a work factor that is easily reachable by a medium botnet or cloud service. Adding a switch to turn these back on would be IMO irresponsible. If you think this is overly parentalistic and that an experienced admin is the one best equipped to assess risk, then I'd direct said experienced admin to the the SSH_RSA_MINIMUM_MODULUS_SIZE definition in sshkey.h that they can adjust themselves. -d
On 02/01/18 11:38, Damien Miller wrote:> If you think this is overly parentalistic and that an experienced > admin is the one best equipped to assess risk, then I'd direct said > experienced admin to the the SSH_RSA_MINIMUM_MODULUS_SIZE definition in > sshkey.h that they can adjust themselves.It is overly paternalistic, to use your word, because it's saying that the user can't be trusted to not use a weak cipher in only those cases where that's the only cipher available.? It's saying that the only acceptable access to said industrial equipment is no access.
On 2 January 2018 at 02:08, Damien Miller <djm at mindrot.org> wrote:> On Fri, 29 Dec 2017, Daniel Kahn Gillmor wrote: > >> On Thu 2017-12-28 21:31:28 -0800, Dan Mahoney (Gushi) wrote: >> > Why not make minimum key length a tunable, just as the other options are? >> >> Because the goal of building secure software is to make it easy to >> answer the question "are you using it securely?" > > This is a nice summation of our approach. It's the same reason we've > never implemented the null cipher and also one of the reasons we removed > SSHv1.Yeah, and broke a lot of institutions and forced them to avoid any further updates. Thanks to your broken policy of breaking backwards compatibility the deployment of ssh has gotten a lot more insecure, i.e. you got exactly the opposite of what you wanted to archive. Maybe its time to have another April RFC, with ssh now as target and with your name on it. I'd propose to make it mandatory for all sshv2 implementations too, and implement a 1 bit key and 1 bit password to make sshv2 exactly that what it has become: Broken Ced -- Cedric Blancher <cedric.blancher at gmail.com> [https://plus.google.com/u/0/+CedricBlancher/] Institute Pasteur
On Tue, 2 Jan 2018, Cedric Blancher wrote:> Maybe its time to have another April RFC, with ssh now as target and > with your name on it. I'd propose to make it mandatory for all sshv2 > implementations too, and implement a 1 bit key and 1 bit password to > make sshv2 exactly that what it has become: BrokenI've not stated this explicitly before, but since this thread has veered into personal attack, let me be explicit now: Abusive language, behaviour or personal attacks are not welcome on this list and I will gleefully ban anyone who makes them. Myself and the other OpenSSH developers are volunteers and while none of us do it for adulation, we certainly don't do it for abuse. We can disagree about technical matters without making it about individuals and without being abusive. -d