openssh unix dev - Dec 2019 - Settable minimum RSA key sizes on the client end for legacy devices.

Unix was not designed to stop you from doing stupid things, because that would
also stop you from doing clever things.
- Doug Gwyn, in Introducing Regular Expressions (2012) by Michael Fitzgerald

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+j.mccanta=f5.com at
mindrot.org> on behalf of Steve Sether <steve at sether.org>
Sent: Friday, December 27, 2019 9:50:28 PM
Cc: openssh-unix-dev at mindrot.org <openssh-unix-dev at mindrot.org>
Subject: Re: Settable minimum RSA key sizes on the client end for legacy
devices.

EXTERNAL MAIL: openssh-unix-dev-bounces+j.mccanta=f5.com at mindrot.org

On 12/27/19 1:46 AM, Philipp Marek wrote:
>> I fully agree with Steve here, and dislike developers' attitude of
"We
>> know what's good for you, and since you don't/can't have a
clue - we
>> won't trust you with decisions".
>
> Well, I'm on the developers' side.
> They need to produce a product that _now_ gets installed in some
> embedded device and is expected to be still secure in 15 years and
> longer - as this thread proves.
>
> So the emphasis _must_ be on conservative defaults.
>
>
> But I've been on the other side as well 20 years ago, trying to run SSH
> on a 200MHz RISC machine... Engineering sometimes needs trade-offs,
> yeah.
>
>
>> Minimal key size should have a "reasonable" default, and an
explicit
>> config parameter to override it and set to whatever value that
>> *specific* installation needs.
>
> No, that's too easy.
> I've seen too many decisions made on such a basis - "just
configure
> security down until it works" - but these invariably lead to disaster.
>
>
I don't think the right decision is to prevent people from doing things
you don't like, and second guessing what they consider secure by
over-riding defaults.  This is sort of the attitude I'm talking about.
It seems entirely reasonable to put the minimum key size as a runtime
option rather than compile-time.  These are the people who own the
computer in question.

Maybe an admin want an even higher minimum key size than 1024 bits.
There's plenty of systems that might still be in service in 20 years,
and perhaps the minimum key size would go up in that time.  Without the
ability to set at runtime, you have to re-compile, which is always much
harder for old systems.

Also, you can still make your system insecure if you want. telnetd is
still supported on Debian system, and at least Centos 7, but not really
recommended of course.

The natural conclusion of the "I'm the parent trying to protect you
from
bad decisions" idea is that everyone else is a child. There's plenty of
people that can understand exactly the risks they're taking with smaller
key sizes, and are still willing to make the tradoff.
> Still, recompilation has a too variable cost (in the dependencies) -
> it's hard to be sure that you _only_ changed that one constant and
> didn't forget something that ./configure would have found etc.
>
>
>> There's no way  the developers can know
>> or evaluate every possible use case or related threat model -
>
> No, they don't.
> They only know the most common 90%, of which eg. _I_ probably
> only know 20%.
>
>
>> so they
>> shouldn't behave as if they do...
>
> Well, like a parent they try to save you from bad decisions.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> Unix was not designed to stop you from doing stupid things, because
> that would also stop you from doing clever things.
> - Doug Gwyn, in Introducing Regular Expressions (2012) by Michael 
> Fitzgerald
Please note that this mostly applies to the priviledged administrative
account - as long as a you're a normal user the other users should be
protected from your mistakes. (g+w etc. is already "extended rights"
;)


In engineering, one of the major points is to foresee potential human
mistakes - and to take precautions to prevent them.

I see that SSH key length issue similar to operating big machinery -
you're protected as long as you use it normally; to tear a limb off
you need to become inventive.

(Search the internet for images "two-hand control".)

"Normal use" should be covered by reasonable defaults. Explicit
parameters are for specific less-standard needs.

It's pretty stupid to harbor a delusional belief that you can correctly
determine and prevent others from doing stupid things. There are exceptions, but
their rarity serves to strengthen the above.

Regards,
Uri
> On Dec 29, 2019, at 11:54, Philipp Marek <philipp at marek.priv.at>
wrote:
> 
> ?
>> 
>> Unix was not designed to stop you from doing stupid things, because
>> that would also stop you from doing clever things.
>> - Doug Gwyn, in Introducing Regular Expressions (2012) by Michael
Fitzgerald
> 
> Please note that this mostly applies to the priviledged administrative
> account - as long as a you're a normal user the other users should be
> protected from your mistakes. (g+w etc. is already "extended
rights" ;)
> 
> 
> In engineering, one of the major points is to foresee potential human
> mistakes - and to take precautions to prevent them.
> 
> I see that SSH key length issue similar to operating big machinery -
> you're protected as long as you use it normally; to tear a limb off
> you need to become inventive.
> 
> (Search the internet for images "two-hand control".)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5874 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20191229/ec3eb968/attachment-0001.p7s>

I think it's entirely reasonable to have a default setting of 1024 bits 
for the minimum key size.? That satisfies the requirement of trying to 
prevent human mistakes.? But if you really want to go and over-ride the 
recommended settings, that's your business.

For instance, both curl and wget have options to not check the ssl 
certificate.? That essentially obviates ssl since MitM attacks become 
trivial.? Firefox allows you to do this as well, though it's obscure: 
https://www.techwalla.com/articles/how-to-disable-invalid-ssl-in-firefox



On 12/29/19 3:46 AM, Philipp Marek wrote:
>> Unix was not designed to stop you from doing stupid things, because
>> that would also stop you from doing clever things.
>> - Doug Gwyn, in Introducing Regular Expressions (2012) by Michael 
>> Fitzgerald
>
> Please note that this mostly applies to the priviledged administrative
> account - as long as a you're a normal user the other users should be
> protected from your mistakes. (g+w etc. is already "extended
rights" ;)
>
>
> In engineering, one of the major points is to foresee potential human
> mistakes - and to take precautions to prevent them.
>
> I see that SSH key length issue similar to operating big machinery -
> you're protected as long as you use it normally; to tear a limb off
> you need to become inventive.
>
> (Search the internet for images "two-hand control".)