On 02/01/18 02:22, Peter Moody wrote:> I would prefer that: > > * commercial vendors patched the software they soldWe all would prefer that, but I think you know that in reality, very few customers have enough leverage to achieve that.? I have a number of IBM servers for which access to the remote console now requires old versions of Java and old browsers.? That's IBM.? If they're not going to update equipment, nobody is.? Let's not pretend the world works differently.> I'm not sure what your bugaboo is about a fractured user base; at > any given time there are probably hundreds of different versions of > openssh being distributed due to different os's, distros, etc.Every older version of openssh is on the path to the latest version, unless there's a reason why the latest version cannot be used.? When you create such a reason, you force them to choose between a real bug or find an alternative.? A lot of people choose to live with a real bug, and that truly does reduce security. But the worst thing about fracturing the user base, from the perspective of wanting to be the premiere implementation of ssh, is you create a real incentive for a fork.? As things stand, a fork would be superior software, because it will have 100% of the goodness of openssh without the badness.? The main distributions will eventually switch and then openssh will become irrelevant. Why go through that over some pig-headed and wrong principle?? (I realise that there are developers here who think that it's not pig-headed to aim for perfect security, but, when you make perfect be the enemy of good, you are being pig-headed.)? What is proposed has a strong argument in its favour, and really has no downside, unless you believe in fairy godmothers who can wave a wand and make manufacturers do things which they clearly are not going to.> by the way, do you not see that every one of your arguments about the > openssh client can be applied, almost verbatim, to the vendor supplied > sshd?I realise.? I also realise that the reason why open source software is so powerful a force in IT is because manufacturers want to their gear to become obsolete, they want it to exist in their own silos, they want to destroy the opposition.? If I said "embrace, extend, extinguish", everybody here would nod their head.? Our job is to provide a better alternative.? This recent change, which removed shorter keys, could have been done slightly differently and we would continue to be a better alternative. Now, sadly, people have to dig into yesteryear and find a better alternative.? That not only sucks, it creates space for a good alternative that will displace openssh. I think a very good question which needs to be asked is, what value does disallowing shorter keys bring over severely deprecating them (i.e. allowing them by use of command argument on a per-session basis)?? I cannot see a single benefit; it won't stop use of shorter keys, it will just stop use of the latest openssh.
> I think a very good question which needs to be asked is, what value does > disallowing shorter keys bring over severely deprecating themlike you said, they have only been severely deprecated. further, you have been told exactly how to enable them, here https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-January/036535.html you seem to want someone else to do all the work for you. good luck with that.
On 02/01/18 16:05, Peter Moody wrote:>> I think a very good question which needs to be asked is, what value does >> disallowing shorter keys bring over severely deprecating them > like you said, they have only been severely deprecated. further, you > have been told exactly how to enable them, here > https://lists.mindrot.org/pipermail/openssh-unix-dev/2018-January/036535.htmlNo, these shorter keys have been disallowed.? There is no way to enable them, other than to modify the software.> you seem to want someone else to do all the work for you.That is not true, and it was rather mean of you to say it.? I am willing to all the work, but there's no point doing that if it's just going to be rejected out-of-hand, which seems to be the case. Your position (per reference above) is that allowing use of shorter keys is irresponsible.? It's not.? It is irresponsible to break other people's equipment (which is what you want to do.)? It is irresponsible (for openssh) to push people to other software.
David Newall wrote:> I think a very good question which needs to be asked is, what value > does disallowing shorter keys bring over severely deprecating them > (i.e. allowing them by use of command argument on a per-session > basis)? I cannot see a single benefit; it won't stop use of shorter > keys, it will just stop use of the latest openssh.At what point is the security hole so great that "deprecation" is no longer acceptable? I can point out 20+ year old devices still running sshv1 only protocol. Do we need to keep this complexity until that number is zero? Even though it has been broken and known insecure for decades. And how many annoying "Do you really want to do this?" type questions do you prompt the user and assume it is "fine"? This is an honest question as that seems to be the core of the issue. What balance between known insecure, complexity (allowing low value keys in the client, prompting the user to verify they want to do this, and disabling it in the server), and removing proven insecure features? Ben
On 02/01/18 16:33, Ben Lindstrom wrote:> And how many annoying "Do you really want to do this?" type questions > do you prompt the user and assume it is "fine"?I think zero.? I think the warning goes in the man page: ? --allow-insecure-short-key? This option allows use of keys shorter than 1024 bits, however, it is known that such keys can be broken quite quickly.? You never want to use this option, unless you are connecting to a server which does not allow a longer key.
David Newall wrote:> On 02/01/18 02:22, Peter Moody wrote: >> I would prefer that: >> >> ? * commercial vendors patched the software they sold > > We all would prefer that, but I think you know that in reality, very few > customers have enough leverage to achieve that.? I have a number of IBM > servers for which access to the remote console now requires old versions > of Java and old browsers.? That's IBM.? If they're not going to update > equipment, nobody is.? Let's not pretend the world works differently.And how are you dealing with this particular case? Do you keep unpatched old browsers on all end-user systems? If yes, good luck... Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20180102/e48143ef/attachment.p7s>