On 30/12/17 09:46, 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?" >That answer is wrong.? The suggestion, which allowed that security was important, allowed for an option which could only be used by explicitly setting it at SSH invocation, so, that means, if you don't use the option then you are (maybe) using it securely, and if you do use the option, then you are using it in the most secure way possible (because you'd only use it when forced to.) By making it impossible for people to use SSH you are forcing people to use less secure software; telnet because they can't use ssh; old, buggy versions of ssh because that's what they had to install so that they could connect to their industrial equipment. The answer is also boneheaded:> remove the devices and replace them with something that is actually > well-supportedWe'd be better removing arrogance from essential development teams, people who think that replacing a world full of expensive and functioning equipment is an option.? It's not, and nor should it be.? That's a disgraceful suggestion and you should be ashamed of yourself. Browser developers got it badly wrong; let's not join them. The suggestion was good because there's a wide-spread need for shorter keys and the suggested solution doesn't allow shorter keys unless explicitly set per invocation.
> By making it impossible for people to use SSHnb, it's not impossible to use opessh. it might not be possible to use a *modern* openssh client to connect to an old, unpatched unmaintained (by the vendor) sshd. i'd argue that's not the client's fault.> you are forcing people to use > less secure software; telnet because they can't use ssh;alternative interpretation. i'm less likely to buy from a vendor who has a history of not keeping their software patched. if everyone else is similarly inclined, vendors will quickly take note.> old, buggy versions > of ssh because that's what they had to install so that they could connect to > their industrial equipment.I'd personally be more worried about the buggy sshd to which I'm connecting. maintaining old code isn't free. if you need the old options, ssh1 support, whatever, you should bear the cost of that yourself (by keeping an old copy around, or compiling it yourself when you need it). that cost shouldn't be borne by the openssh developers and not the ret of the community.
On 31/12/17 13:52, Peter Moody wrote:>> By making it impossible for people to use SSH > nb, it's not impossible to use opessh. it might not be possible to use > a*modern* openssh client to connect to an old, unpatched unmaintained > (by the vendor) sshd. i'd argue that's not the client's fault.Of course it's the client's fault.? The client worked, was changed, and thus stopped working.? The client wasn't faulty before, and the difference was that some people thought it would be a good idea to break compatibility with other standard-compliant software.? That's got to be the definition of "client's fault" (where "client" means "the people who modified the client".)>> you are forcing people to use >> less secure software; telnet because they can't use ssh; > alternative interpretation. i'm less likely to buy from a vendor who > has a history of not keeping their software patched. if everyone else > is similarly inclined, vendors will quickly take note.You're blaming the victim?? It's their fault for lacking prescience?>> old, buggy versions >> of ssh because that's what they had to install so that they could connect to >> their industrial equipment. > I'd personally be more worried about the buggy sshd to which I'm connecting.By all means worry about that; but there's no suggestion that the server, in this case, is buggy.> maintaining old code isn't free. if you need the old options, ssh1 > support, whatever, you should bear the cost of that yourself (by > keeping an old copy around, or compiling it yourself when you need > it). that cost shouldn't be borne by the openssh developers and not > the ret of the community.The developers fucked up.? They chose to expend effort breaking backwards compatibility when they didn't have to.? For the same effort they could have deprecated shorter keys without disallowing them. But, by all means, force people to use old versions.? That's got to advance security, doesn't it?? Who knows, maybe you might even cause a fork.? Then there'd be openssh, which doesn't work with lots and lots of stuff, and there'd be universalssh which works with everything, which has all of the latest goodness of openssh (because, why wouldn't it?) without any of the nastiness.? Then Debian and Red Hat would switch, and openssh would become an also-ran.? Not a terrible result for the world but a bad look for the core openssh developers.