while encrypted NFS with Kerberos is its own bespoke, unique cryptographic protocol and implementation.

I suppose that's true; although Kerberos encryption in general is also reasonably hardened over the years (with MS Active Directory being a heavy user; e.g. all AD LDAP traffic is Kerberos-encrypted instead of using TLS), but unlike TLS it indeed needs to be custom-integrated into each protocol, e.g. with SunRPC there is certainly a downside that it only encrypts the RPC call payloads but not headers.

(Though in practice for NFSv4, the only visible RPC operation is "COMPOUND", with the real ops inside the secure payload so it doesn't reveal anything really, but I'm not sure whether that's "secure by accident" or "secure by design".)

Similarly with SMBv3, the custom encryption feature does not protect authentication (it uses the auth mechanism to derive keying), so while it is fine with Kerberos, it really does not help much when used with NTLM... (And SMB-over-QUIC is apparently a thing now, but of course only for those who pay for Azure.)

One part of my answer is 'agility'. SMTP was able to add TLS because it could add a 'STARTTLS' command to the protocol and get people to use it; IMAP was able to add TLS partly because it could also add a 'STARTTLS' command and partly because it was able to add an entire new TCP port that was 'IMAP over TLS'. As a practical matter, NFS has never had this agility; the existing NFS protocols had no easy place to add the equivalent of EHLO and STARTTLS

I'm not sure that's right, exactly; for years NFS has had the "NULL" RPC function both to negotiate between existing security mechanisms (if you don't specify the correct one at mount time), and to set up a GSS context for Kerberos (as Kerberos itself is already not completely stateless if you want its integrity or encryption services).

So it appears that's exactly how they implemented RPC-TLS as well – essentially adding a "STARTTLS" pseudo-mechanism to the same NULL operation.

and the IP ports to use were either fixed or found in arcane ways that made it hard to add a new port for an all-TLS version.

For NFSv4 (which only has a single well-known port) I believe it certainly could've been done the same way as with other TLS-ified protocols, e.g. `mount -o tls` could have implied `-o port=XYZ`.

For NFSv2/3, where portmapper was a thing, I suppose it could've been achieved by defining NFS-over-TLS as a new RPC "program"?

This means that a straightforward version of 'NFS over TLS' is encrypting the (TCP) transport stream, not 'NFS' as such. There are similar protocol challenges with DNS over TLS.

This is really the same with all protocols, though. IMAPS doesn't change how IMAP works either, it only encrypts the underlying stream; on the other hand, DNS-over-TCP has always been a thing and putting it inside a TLS tunnel was possible without much change in the way it works.

The deepest reason I see is that we never successfully created a generic 'random TCP streams over encryption' system that could be applied to encrypt something without the cooperation of the protocol. People sort of tried in the form of IPsec, but for various reasons IPsec has not caught on and isn't considered desirable today.

From what I know, IPsec in the form of IKEv2 is quite alright security-wise (a bit less hassle than IKEv1 was, and many of the proprietary tweaks to IKEv1 such as Cisco-style authentication are now built-into IKEv2), though it's still annoying to set up compared to e.g. WireGuard.

Though, I believe much of its apparent complexity comes from the fact that

"as opposed to simply specifying 'this traffic should be encrypted' (a feature that IPsec did support)"

is not merely "possible" but baked hard into Linux IPsec implementations, to the point that it makes simple "VPN-like" usage annoyingly difficult. (Only recently did Linux finally add virtual "xfrmi" interfaces...) If only strongSwan could be asked to give a userspace tun interface like normal.

The unencrypted IMAP and SMTP protocols are both stream focused protocols. Each starts with a stream setup phase (IMAP login, SMTP EHLO, etc) and proceeds through a series of steps where the state of the stream provides critical context. In both of them, it's clear what happens if the stream is broken for some reason; you have to start over with another stream setup and re-establish the context. NFS is not like this; the TCP stream is an implementation detail of the transport mechanism, not a core element of the protocol (and historically NFS was transported over UDP first). I believe that NFS clients typically use one TCP stream to transport all RPC for a particular server, but they aren't required to. If a NFS TCP connection breaks, re-establishment is supposed to be more or less transparent to the RPC layer, and the stream carries little or no context for the RPC operations.

It's my view that this difference matters. For example, you can argue that the correct thing to encrypt is NFS RPC operations and replies (and then continue to transport them over unencrypted TCP), whereas encrypting only the IMAP or SMTP commands and replies in an unencrypted TCP stream is relatively obviously crazy, partly because the overall integrity of the TCP stream is critical for SMTP and IMAP (since all IMAP and SMTP commands are issued in a context established by the state of the stream; if you can replay or splice in operations you can damage or destroy that state and cause valid commands from the client to go wrong, so the state must be protected).

(I'd argue that the overall integrity of the sequence of NFS RPCs and replies is also of high importance, but I'm not certain I'd win that argument and I'd expect people to try to put together clever RPC level encryption schemes to achieve it instead of encrypting the entire stream.)

Overall I have quite a different view from our blogger on these issues, to summarize:

• There is a lot of difference between encryption for authentication (where usually encryption costs don't matter much) and for confidentiality.

• There is no practical alternative for authentication to Kerberos.

• Kerberos for NFS (and SMB/CIFS, AFS, and other filesystems) authentication works pretty well and has large benefits, such as the ability to enforce user/group access control at the server, plus the other advantages of Kerberos such as the ability to forward credentials.

• Kerberos for NFS data confidentiality was a mistake, but for some people it was better-than-nothing.

• Kerberos used to be annoying to setup for the Linux in-kernel driver, but fortunately it is quite easy to setup with the NFS Ganesha implementation, especially with NFS4.

• IPSEC for data confidentiality works very well (and in part for host authentication), but it has come into widespread usability only with AES+GCM special instructions.

• Before AES and AES+GCM instructions not only encryption was quite expensive and mostly usable only for authentication, it was also subject to extensive government suppression that made it risky, Therefore the prevalence of special-case encryption and in off-mainstream tools (e.g. Linux and SSH), and mostly anyhow for authentication. SSL initially was itself off-mainstream until it came to the attention of the authorities.

• Regardless of speed and government suppression, the big problem with any encryption scheme, whether for authentication or confidentiality, is key distribution. The popularity of SSH seems to me largely based not only on its relative initial obscurity, compared to SSL too, but also on its not being associated with any kind of built-in PKI (which is also a significant risk in the hands of the sillies, but also makes it much easier to get into). That is why I think SSH (despite its terrible misdesigns) became far more popular than TELNET+SSL or TELNET+IPSEC, to the ridiculous point that IP-over-SSH is probably far more popular than IPSEC itself.

• The best chance for IPSEC is accordingly the "strongSwan" implementation, which can use existing public and private SSH key pairs for authentication (AES+GCM with AES-NI for confidentiality) and thus is quite trivial to setup.