Mailing List Archive

You can use openssl to generate a shorter key:

$ openssl genprsa -out key.pem 768
$ ssh-keygen -y -f key.pem > key.pub # optional to get public key

This works with a 768-bit RSA key (client: OpenSSH_7.2p2, OpenSSL
1.0.2g; server: OpenSSH_7.2p2, OpenSSL 1.0.2g) but not a 256-bit RSA
key: I can generate the shorter key but the server requires a minimum of
768-bits.

Hope this helps.



-------- Forwarded Message --------
Subject: Settable minimum RSA key sizes on the client end for legacy
devices.
Date: Wed, 25 Dec 2019 21:02:36 -0600
From: Steve Sether <steve@sether.org>
To: openssh-unix-dev@mindrot.org



Recently I tried to turn on SSH on my 12 year old APC-UPS.  I soon
discovered that I couldn't connect to it because my newer version of
openssh doesn't support RSA key sizes below 1024 bits.

I'd rather not dredge up a big fight, but I _would_ like to express a
desire for some form of overriding the minimum key size.  Basically I've
had to turn on telnet access again, lowering security.  The HTTPS
protocol options on the device are old enough that no modern browser
will connect to it either.  So essentially I'm left at going back to the
mid 90s and use telnet, or HTTP to connect to this device.

To me, not providing a way to over-ride the minimum key size is just a
bit heavy-handed.  The vendor doesn't support this device anymore, and
it's failed all attempts at replacing the 768 bit key with a 1024 bit
one.  The firmware is upgraded to the last release in 2010. I understand
that a 768 bit RSA key was factored 10 years ago, though with a very
large computing effort, so it's vulnerable to a pretty expensive attack.

I note that other legacy, potentially insecure options are supported via
configuration changes. https://www.openssh.com/legacy.html Why isn't the
same true for a minimum key size?  This device isn't exactly ancient at
around 12 years old and a 10 year old firmware.  I'd imagine there's
other hardware that has limited support for ssh key sizes that the
current openssh won't connect to anymore.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2019/12/25 21:02, Steve Sether wrote:
> Basically I've had to turn on telnet access again, lowering security.

Does it really lower security? The very old embedded OS is not going to
be secure anyway, this type of device should only be used on a trusted
private network. (New embedded OS are often not much better so I'd take
the same view there).

The RNG used to generate the key is probably rubbish too - I don't expect
there to be all that much entropy in those 768 bits..

Not being able to use ssh is an annoyance but there are trade-offs to be
made when using old hardware. The way I deal with these is to use telnet
from a console server / "jump box" which itself runs modern sshd.

> To me, not providing a way to over-ride the minimum key size is just a bit
> heavy-handed.? The vendor doesn't support this device anymore, and it's
> failed all attempts at replacing the 768 bit key with a 1024 bit one.

The APC devices I used struggled with even a 768-bit key, I suspect
handling numbers 2^256 times larger will be too hard on the CPU.

> I note that other legacy, potentially insecure options are supported via
> configuration changes. https://www.openssh.com/legacy.html

Most of these (though not ssh-dss) relate to per-session keying.
I think you can get away with a bit more weakness there (which would
have to be attacked while the session is active and before rekeying)
whereas short host keys are more of a long term risk.

Note that other things were removed with no fallback available (also
with good reason) - SSH1 for example.

> Why isn't the
> same true for a minimum key size?? This device isn't exactly ancient at
> around 12 years old and a 10 year old firmware.? I'd imagine there's other
> hardware that has limited support for ssh key sizes that the current
> openssh won't connect to anymore.

The other place I've seen it is on old switches but there is usually
less reason to keep them than old power control hardware.

> I'd rather not dredge up a big fight, but I _would_ like to express a
> desire for some form of overriding the minimum key size.

This can be done by recompiling if necessary. This restriction has been
a pain for me at times but honestly I think it's for the best that it's
been done.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

>> I'd rather not dredge up a big fight, but I _would_ like to express a
>> desire for some form of overriding the minimum key size.
>
> This can be done by recompiling if necessary. This restriction has been
> a pain for me at times but honestly I think it's for the best that it's
> been done.

I may be alone with that opinion, but for such things I've always hoped
for a global _variable_ whose location is available as a dynamic symbol
in the ELF - so instead of getting all the sources (and all their
dependencies, resp. the headers etc.) and reconfiguring (with all
required research to get the right options) and recompiling, a 1-minute
session with a hex editor to patch the 2 bytes would be enough...


Yeah, some distributions make recompilation much easier (Debian has
"apt-get source") - but still it's much more work than switching a few
bytes.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 12/26/19 6:35 AM, Stuart Henderson wrote:
> On 2019/12/25 21:02, Steve Sether wrote:
>> Basically I've had to turn on telnet access again, lowering security.
> Does it really lower security? The very old embedded OS is not going to
> be secure anyway, this type of device should only be used on a trusted
> private network. (New embedded OS are often not much better so I'd take
> the same view there).
>
> The RNG used to generate the key is probably rubbish too - I don't expect
> there to be all that much entropy in those 768 bits..
>
> Not being able to use ssh is an annoyance but there are trade-offs to be
> made when using old hardware. The way I deal with these is to use telnet
> from a console server / "jump box" which itself runs modern sshd.

For me personally?  No.  This is my home device, and I'm not really all
that worried. For a lot of companies in the world? Absolutely.  This is
primarily because it's extremely common to re-use administrator
passwords.  Sniff some network traffic and raise your privilege level. 
I think most people agree that the perimeter defense is not something
you should rely on, and to use encryption inside your own network.  I
understand that one can perform mitigations to lower the risk, but it
just doesn't make sense to me that openSSH has decided to not support this.

I've no doubt that someone could (likely) hack into the APC-UPS device
with enough effort.  I don't personally know of any vulnerabilities for
this device, (and I did just check).  So hacking into it would take some
effort, finding an exploit, writing some kind of means to obtain a
password from the device, etc.  Sniffing telnet and doing ARP poisoning
attacks and the like is pretty trivial by comparison.  These are well
known ways to obtain passwords that have been around for 20+ years, and
the very reason ssh was invented in the 90s.

Someone here suggested generating a 1024 bit RSA key offline and
uploading it.  That's exactly what I tried doing, and the APC rejected
it.  I suspect because, as you say below, the CPU isn't powerful enough
for a 1024 bit key.

>> To me, not providing a way to over-ride the minimum key size is just a bit
>> heavy-handed.  The vendor doesn't support this device anymore, and it's
>> failed all attempts at replacing the 768 bit key with a 1024 bit one.
> The APC devices I used struggled with even a 768-bit key, I suspect
> handling numbers 2^256 times larger will be too hard on the CPU.
>
>> I note that other legacy, potentially insecure options are supported via
>> configuration changes. https://www.openssh.com/legacy.html
> Most of these (though not ssh-dss) relate to per-session keying.
> I think you can get away with a bit more weakness there (which would
> have to be attacked while the session is active and before rekeying)
> whereas short host keys are more of a long term risk.
>
> Note that other things were removed with no fallback available (also
> with good reason) - SSH1 for example.

ssh1 I can certainly understand, primarily because maintaining the
protocol requires maintenance.  I don't see a huge amount of maintenance
in a config option for minimum key size.  I also don't know that I've
seen a device that only supports SSH1.  IIRC ssh2 came out in something
like 1996, shortly after ssh1.  I'm not even sure if ssh1 really gained
much popularity, since those early days it was just Tatu with his idea
of encrypted telnet.

I guess my main problem with setting this hard-coded is that it puts a
LOT of control in the hands of the developers, and little or no control
in the system administrators.  i.e. "We Know What's Good For You!". 
Well, not for everyone.  One size rarely fits all.


>> Why isn't the
>> same true for a minimum key size?  This device isn't exactly ancient at
>> around 12 years old and a 10 year old firmware.  I'd imagine there's other
>> hardware that has limited support for ssh key sizes that the current
>> openssh won't connect to anymore.
> The other place I've seen it is on old switches but there is usually
> less reason to keep them than old power control hardware.
>
>> I'd rather not dredge up a big fight, but I _would_ like to express a
>> desire for some form of overriding the minimum key size.
> This can be done by recompiling if necessary. This restriction has been
> a pain for me at times but honestly I think it's for the best that it's
> been done.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Yes, I considered re-compiling, but it just seemed like an enormous pain
to have to go through the source and figure out where the key size limit
was.  It also occurred to me that I'm likely not the only one with this
problem, but many just didn't understand what the underlying problem
was, and more wouldn't know where to go to talk about addressing it. 
95% of the administrators of the world are just going to enable telnet,
and be done with it.  You have to remember that one person reporting a
bug or requested feature represents many, many more that never caught
it, or didn't know how to report it, or (as above) found another workaround.

I also tried looking for other clients that might support lower sized
keys.  putty seems to blow up because of the buggy ssh implementation of
the server that openSSH kindly deals with. There's some other
implementations that I didn't want to pay for just to see if they worked.

On 12/26/19 8:08 AM, Philipp Marek wrote:
>
>>> I'd rather not dredge up a big fight, but I _would_ like to express a
>>> desire for some form of overriding the minimum key size.
>>
>> This can be done by recompiling if necessary. This restriction has been
>> a pain for me at times but honestly I think it's for the best that it's
>> been done.
>
> I may be alone with that opinion, but for such things I've always hoped
> for a global _variable_ whose location is available as a dynamic symbol
> in the ELF - so instead of getting all the sources (and all their
> dependencies, resp. the headers etc.) and reconfiguring (with all
> required research to get the right options) and recompiling, a 1-minute
> session with a hex editor to patch the 2 bytes would be enough...
>
>
> Yeah, some distributions make recompilation much easier (Debian has
> "apt-get source") - but still it's much more work than switching a few
> bytes.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

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. There's no way the developers can know or evaluate every possible use case or related threat model - so they shouldn't behave as if they do...

Regards,
Uri

> On Dec 26, 2019, at 15:30, Steve Sether <steve@sether.org> wrote:
>
> ?
>> On 12/26/19 6:35 AM, Stuart Henderson wrote:
>>> On 2019/12/25 21:02, Steve Sether wrote:
>>> Basically I've had to turn on telnet access again, lowering security.
>> Does it really lower security? The very old embedded OS is not going to
>> be secure anyway, this type of device should only be used on a trusted
>> private network. (New embedded OS are often not much better so I'd take
>> the same view there).
>>
>> The RNG used to generate the key is probably rubbish too - I don't expect
>> there to be all that much entropy in those 768 bits..
>>
>> Not being able to use ssh is an annoyance but there are trade-offs to be
>> made when using old hardware. The way I deal with these is to use telnet
>> from a console server / "jump box" which itself runs modern sshd.
>
> For me personally? No. This is my home device, and I'm not really all that worried. For a lot of companies in the world? Absolutely. This is primarily because it's extremely common to re-use administrator passwords. Sniff some network traffic and raise your privilege level. I think most people agree that the perimeter defense is not something you should rely on, and to use encryption inside your own network. I understand that one can perform mitigations to lower the risk, but it just doesn't make sense to me that openSSH has decided to not support this.
>
> I've no doubt that someone could (likely) hack into the APC-UPS device with enough effort. I don't personally know of any vulnerabilities for this device, (and I did just check). So hacking into it would take some effort, finding an exploit, writing some kind of means to obtain a password from the device, etc. Sniffing telnet and doing ARP poisoning attacks and the like is pretty trivial by comparison. These are well known ways to obtain passwords that have been around for 20+ years, and the very reason ssh was invented in the 90s.
>
> Someone here suggested generating a 1024 bit RSA key offline and uploading it. That's exactly what I tried doing, and the APC rejected it. I suspect because, as you say below, the CPU isn't powerful enough for a 1024 bit key.
>
>>> To me, not providing a way to over-ride the minimum key size is just a bit
>>> heavy-handed. The vendor doesn't support this device anymore, and it's
>>> failed all attempts at replacing the 768 bit key with a 1024 bit one.
>> The APC devices I used struggled with even a 768-bit key, I suspect
>> handling numbers 2^256 times larger will be too hard on the CPU.
>>
>>> I note that other legacy, potentially insecure options are supported via
>>> configuration changes. https://www.openssh.com/legacy.html
>> Most of these (though not ssh-dss) relate to per-session keying.
>> I think you can get away with a bit more weakness there (which would
>> have to be attacked while the session is active and before rekeying)
>> whereas short host keys are more of a long term risk.
>>
>> Note that other things were removed with no fallback available (also
>> with good reason) - SSH1 for example.
>
> ssh1 I can certainly understand, primarily because maintaining the protocol requires maintenance. I don't see a huge amount of maintenance in a config option for minimum key size. I also don't know that I've seen a device that only supports SSH1. IIRC ssh2 came out in something like 1996, shortly after ssh1. I'm not even sure if ssh1 really gained much popularity, since those early days it was just Tatu with his idea of encrypted telnet.
>
> I guess my main problem with setting this hard-coded is that it puts a LOT of control in the hands of the developers, and little or no control in the system administrators. i.e. "We Know What's Good For You!". Well, not for everyone. One size rarely fits all.
>
>
>>> Why isn't the
>>> same true for a minimum key size? This device isn't exactly ancient at
>>> around 12 years old and a 10 year old firmware. I'd imagine there's other
>>> hardware that has limited support for ssh key sizes that the current
>>> openssh won't connect to anymore.
>> The other place I've seen it is on old switches but there is usually
>> less reason to keep them than old power control hardware.
>>
>>> I'd rather not dredge up a big fight, but I _would_ like to express a
>>> desire for some form of overriding the minimum key size.
>> This can be done by recompiling if necessary. This restriction has been
>> a pain for me at times but honestly I think it's for the best that it's
>> been done.
>>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> 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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 27/12/19 6:16 pm, 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.

What this thread proves is that we didn't make a SSH that was secure for
15 years.  We did attempt to break old systems; how rude of us.  We
shouldn't do that.


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

It's not a bad idea.


> I've seen too many decisions made on such a basis - "just configure
> security down until it works" - but these invariably lead to disaster.

Hyperbole much?  No need for...

> Well, like a parent they try to save you from bad decisions.

...arrogance.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@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

Get Outlook for iOS<https://aka.ms/o0ukef>
________________________________
From: openssh-unix-dev <openssh-unix-dev-bounces+j.mccanta=f5.com@mindrot.org> on behalf of Steve Sether <steve@sether.org>
Sent: Friday, December 27, 2019 9:50:28 PM
Cc: openssh-unix-dev@mindrot.org <openssh-unix-dev@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@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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@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".)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

"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@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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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".)
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev