TrueNAS 13.3 Wishlist

[Arwen]

The difficulty with Linux kernels extends beyond just compiling and staying up with kernel versions.

It is the break in kernel configuration compatibility with each release. Now if you truly can stay on a LTS kernel release, this "breakage" is once a year, so not too bad. But I have seen some strange config file changes in various kernel jumps. And yes, for the last 4 or more years I have stuck with Linux LTS kernels on everything at home, (except with my new laptop... it will move to LTS soon, if not already.)

What I mean by break in kernel configuration is that the current ".config" file does not completely translate to the next LTS kernel. It will work, (at least for me), very well on minor updates, like 6.1.31 to 6.1.50. But, jumps in major versions like from 6.1.x to 6.6 will require more than trivial manual updates. (Again my own experience.)

A big company dealing with a single major Linux kernel version jump once per year is very doable. Just takes time. You want all the network driver updates, and other things NASy or server things. But, you DON'T want joy stick support, force feed back drivers, sound drivers, and other ridiculous things for a NAS server that might be automatically included.

 

[Arwen]

I'm not a cryptographer, but my understanding is that RSA (with proper hashes) is thought to be about as good as elliptic curves. The default for RSA is probably sha256, from upstream OpenSSH.

Shorter RSA key lengths are considered too weak. My home RSA key is now 8K and work requested a minimum of 4K at least 4 years ago.

 

[morganL]

Considering that TC 13.1 has been postponed to the RC version in April 24, samba 4.20 should be a version update worth considering.

We'll be using the same SAMBA as used in Dragonfish (BETA has started).... it will mean we have much better test time and compatibility. So 4.19 by default.

If there are any specific improvements that are in 4.20 that are needed for your use-case, please bring them up in another thread.

 

[morganL]

Shorter RSA key lengths are considered too weak. My home RSA key is now 8K and work requested a minimum of 4K at least 4 years ago.

Does that translate into any specific requests for SCALE or CORE?

 

[danb35]

I assume the SCALE ACME DNS works with EasyDNS??

No, as of right now, SCALE supports only OVH, Cloudflare, and Route53, in addition to "script" (which will let it call an external script to make the updates). If SCALE (and CORE, for that matter) is using acme.sh under the hood as I suspect they are, then yes, it supports EasyDNS.

 

[Arwen]

I'm not a cryptographer, but my understanding is that RSA (with proper hashes) is thought to be about as good as elliptic curves. The default for RSA is probably sha256, from upstream OpenSSH.

Shorter RSA key lengths are considered too weak. My home RSA key is now 8K and work requested a minimum of 4K at least 4 years ago.

Does that translate into any specific requests for SCALE or CORE?

I am not sure. A quick search on SSH RSA key length found this;

Should I use 2048 or 4096 RSA key?
A 4096 bit key does provide a reasonable increase in strength over a 2048 bit key, and according to the GNFS complexity, encryption strength doesn't drop off after 2048 bits. There's a significant increase in CPU usage for the brief time of handshaking as a result of a 4096 bit key.
Jul 12, 2021

I do know that 2048 RSA key length is considered too short today. (And has been too short for a few years.)

Just now I read in the ssh-keygen manual page that the default is now 3072;
-b bits Specifies the number of bits in the key to create. For RSA keys, the minimum size is 1024 bits and the default is 3072 bits. Generally, 3072 bits is considered sufficient. ...

Not sure how TrueNAS deals with SSH keys as I don't remote replicate. And simple SSH key logins are trivial for me to setup once via password login, and use forever.

The GUI Replication over SSH in TrueNAS SCALE 23.10.1.3 allows creation of SSH keys, though it does not specify what type or size. It might be better to have the SSH key generation under the Credentials, Local Users section.

But, if possible you may want to have a security alert, (warning only), attempt to detect SSH RSA keys used for replication that are too short. As in less than 3072 bits.

 

[rvassar]

Shorter RSA key lengths are considered too weak. My home RSA key is now 8K and work requested a minimum of 4K at least 4 years ago.

I'd consider 4K now the minimum, if not too short. And go to all the trouble to build your own /etc/ssh/moduli. The distro releases are no doubt rainbow tabled... (aka: pre-computed...)

 

[morganL]

Thanks for all the direct feedback. We will start our analysis with this wishlist. Where Dragonfish has not proven a feature, it will be unlikely to make it into CORE 13.3. Stability is a critical goal given the large and sometimes mission-critical userbase.

 

[Ericloewe]

A few of those are good low-hanging fruit:

• The tool updates (smartmontools , etc.) - straightforward updates, not likely to break things
• mpr temperature readout - fairly easy, just needs thought on the GUI side and testing to ensure everything works for arbitrary numbers of HBAs (zero to however many a dev can cram into a machine)
• Config restore from the .system dataset - low-risk, straightforward integration with existing APIs

 

[danb35]

Config restore from the .system dataset - low-risk, straightforward integration with existing APIs

...and this one could really stand to be in SCALE too.

 

[Ericloewe]

...and this one could really stand to be in SCALE too.

Of course, goes without saying. Very low-hanging fruit with potentially big impact in the kinds of situations where users are most nervous ("Ooops, my system just caught fire and I don't have a config backup, but my disks are okay.") in terms of length of outages.

 

[Arwen]

* Config restore from the .system dataset - low-risk, straightforward integration with existing APIs

We just had a forum post about a user that had an issue, but used the restore to default console menu command. Then, user was *issed off that it did exactly what it said it would do.

To be fair, that command should bring up warning that describes what it is going to do in more detail. Then require the person to type "yes" to continue. Or even worse, "yes I know".

 

[Whattteva]

Shorter RSA key lengths are considered too weak. My home RSA key is now 8K and work requested a minimum of 4K at least 4 years ago.

Could just use ed25519 for equivalent strength, but much shorter key length. Though some really old machines may not support it.

 

[Arwen]

Could just use ed25519 for equivalent strength, but much shorter key length. Though some really old machines may not support it.

This is from a recent ssh-keygen manual page;

Code:

       -b bits
...
          ECDSA-SK, Ed25519 and Ed25519-SK keys have a fixed length and the -b flag will be ignored.

This states that Ed25519 is fixed length security. Where RSA can use longer keys for higher security, Ed25519 can not.

 

[nabsltd]

This states that Ed25519 is fixed length security. Where RSA can use longer keys for higher security, Ed25519 can not.

The 256-bit keys that Ed25519 uses along with the SHA-512 signature length require about the same computation as a 3000-bit RSA key using SHA-512. Since many people are using SHA-256 as the signature length even with 4096 bit keys, Ed25519 is already close to a 8192-bit RSA key.

None of this matters, though, since even if the entire world is trying to break your key, most of these are safe for about the next 80 years: https://crypto.stackexchange.com/qu...-rsa-key-is-considered-secure-today/1982#1982

Every year, 32 more bits worth of key become vulnerable, so it will be 2048 before the 2048 bit RSA becomes routinely breakable, and 64 more years before a 4096-bit key becomes breakable. Elliptical keys use completely different methods, so they can be much shorter (and the encryption routines run much faster and use less memory) for the same amount of security, so a 256-bit EC key is good until about 2060.

 

[Arwen]

The 256-bit keys that Ed25519 uses along with the SHA-512 signature length require about the same computation as a 3000-bit RSA key using SHA-512. Since many people are using SHA-256 as the signature length even with 4096 bit keys, Ed25519 is already close to a 8192-bit RSA key.

None of this matters, though, since even if the entire world is trying to break your key, most of these are safe for about the next 80 years: https://crypto.stackexchange.com/qu...-rsa-key-is-considered-secure-today/1982#1982

Every year, 32 more bits worth of key become vulnerable, so it will be 2048 before the 2048 bit RSA becomes routinely breakable, and 64 more years before a 4096-bit key becomes breakable. Elliptical keys use completely different methods, so they can be much shorter (and the encryption routines run much faster and use less memory) for the same amount of security, so a 256-bit EC key is good until about 2060.

Today, (with semi-current OpenSSH), the default is SHA-512. I don't know when this changed.

Code:

       -O option
...
               hashalg=algorithm
                       Selects  the hash algorithm to use for hashing the message to be signed.  Valid algorithms
                       are "sha256" and "sha512." The default is "sha512."
...
       -t dsa | ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa
               Specifies  the  type  of  key  to  create.   The  possible  values are "dsa", "ecdsa", "ecdsa-sk",
               "ed25519", "ed25519-sk", or "rsa".

               This flag may also be used to specify the desired signature type when signing  certificates  using
               an  RSA  CA  key.  The available RSA signature variants are "ssh-rsa" (SHA1 signatures, not recom-
               mended), "rsa-sha2-256", and "rsa-sha2-512" (the default).

 

[morganL]

From our 1st pass here are the ones we expect to include in TrueNAS CORE 13.3:

We're still reviewing the others. However, if the feature is not in SCALE dragonfish and hence tested there, it's unlikely to make it into 13.3.

 

[dak180]

From our 1st pass here are the ones we expect to include in TrueNAS CORE 13.3:

For the ones that do not have a ticket listed can you elaborate as to which, if any, posts in this thread they address?

 

[winnielinnie]

@morganL, please see post #5 in regards to NUT.

 

[cobrakiller58]

@morganL, please see post #5 in regards to NUT.

2.8.1 is what I saw in freshports, is that not the version you are talking about?