Re: Why TLS and Kerberos are not useful for NFS security Re: [PATCH nfs-utils] exportfs: make "insecure" the default for all exports

[Chuck Lever <chuck.lever@oracle.com>]

On 5/14/25 5:50 PM, Martin Wege wrote:
> On Wed, May 14, 2025 at 1:55 PM NeilBrown <neil@brown.name> wrote:
>>
>> On Wed, 14 May 2025, Jeff Layton wrote:
>> Ignoring source ports makes no sense at all unless you enforce some other
>> authentication, like krb5 or TLS, or unless you *know* that there are no
>> unprivileged processes running on any client machines.
> 
> I don't like to ruin that party, but this is NOT realistic.
> 
> 1. Kerberos5 support is HARD to set up, and fragile because not all
> distributions test it on a regular basis. Config is hard, not all
> distributions support all kinds of encryption methods, and Redhat's
> crusade&maintainer mobbing to promote sssd at the expense of other
> solutions left users with a half broken, overcomplicated Windows
> Active Directory clone called sssd, which is an insane overkill for
> most scenarios.
> gssproxy is also a constant source of pain - just Google for the
> Debian bug reports.
> 
> Short: Lack of test coverage in distros, not working from time to
> time, sssd and gssproxy are more of a problem than a solution.
> 
> It really only makes sense for very big sites and a support contract
> which covers support and bug fixes for Kerberos5 in NFS+gssproxy.

Brief general comment: We are well aware of the administrative
challenges presented by Kerberos. :-)


> 2. TLS: Wanna make NFS even slower? Then use NFS with TLS.
> 
> NFS filesystem over TLS support then feels like working with molasses.

We'd like to hear quantitative evidence. In general, TLS with a NIC
that has encryption offload is going to be faster than NFS/Kerberos with
the privacy service. krb5p cannot be offloaded, full stop.

An increasing number of encryption-capable NICs are reaching the
marketplace, and the selection of encryption algorithms available for
TLS includes some CPU-efficient choices.

Thus our expectation is that TLS will become a more performant
solution than Kerberos. In addition, the trend is towards always-on
encryption (QUICv1). IMO you will not be able to avoid encryption-in-
transit in the future.


> Exacerbated by Linux's crazy desire to only support hyper-secure
> post-quantum encryption method (so no fast arcfour, because that is
> "insecure", and everyone is expected to only work with AMD
> Threadripper 3995WX), lack of good threading through the TLS eye of
> the needle, and LACK of support in NFS clients.

I believe the IETF has also broadly discouraged the use of easy-to-
defeat encryption algorithms. Perhaps this desire is not limited to only
Linux.

Using a deprecated encryption algorithm means you get very little
real security in addition to worse performance, so it's not a good
choice.


> Interoperability is also a big problem (nay, it's ZERO
> interoperability), as this is basically a Linux kernel client/kernel server only
> solution.
> libtirpc doesn't support TLS, Ganesha doesn't support TLS, so yeah,
> this is an issue, and not a solution.
> 
> Fazit: Supporting your argumentation with Kerberos5 or TLS is not gonna fly.

I don't think Jeff was suggesting that everyone can just switch
to using cryptography-based security. The point is that real security is
not provided by a cleartext 32-bit word in a network header, and we
should not continue pretending that it is.


-- 
Chuck Lever