openssh unix dev - Jan 2018 - Legacy option for key length?

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.
> 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 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.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.html
No, 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>