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

> 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.


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.

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.

Seems I wasn't clear enough on my main point -

     I'm not an SSH developer,
     and I _want_ to be protected by sane limits here!

>>> 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.
Yeah, right. But owning something doesn't mean you know or can estimate
the second- or third-order changes you cause.

If the key-length runtime option goes down as far as you like, you
might be vulnerable to a timing attack - or a transmit-power
analysis for embedded CPUs with a Wifi, like a Raspberry Pi.


Security isn't a one-dimensional thing that can be measured in a single
bit length - it has so many facets, most of which one wouldn't even
think of.

> 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.
Yeah, right. Current SSH allows already "-b 16384", that should be
safe
enough for a few years.
So _longer_ keys than default isn't the issue here.

> 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.
Yeah, of course security can be degraded in oh so many ways.

> The natural conclusion of the "I'm the parent trying to protect
you
> from bad decisions" idea is that everyone else is a child.
Well, that's the point that I couldn't communicate.
I _long_ for
a) sane defaults that are good enough for a few years, and
b) sane limits that prevent me from doing something stupid.

> 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.
Sorry, no.
There are lots of people who hope to achieve something (faster
connection establishment, less CPU or battery use, backwards
compatibility, ...) by reducing security.

Some of these are true engineering trade-offs, and are okay.


I simply think that having some hard-coded limits
that are not easily removed via a google search and a config option
makes people ask other people for advice,
who then not only say "change #define and recompile" but also
mention some second-order consequences that are not obvious.



All that said, I'm well aware that for the problem that originated this
thread "recompile ssh-keygen and ssh to have smaller limits" is a
valid
first-order technical solution.

OTOH, a complete threat-analysis would have to include the (monetary and
environmental) cost of a new device, the time spent analysing,
discussing, and then fixing the SSH key length, the potential risk of
this device being attacked and instructed to catch fire, and so on.

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