TLS certificates for NFS-over-TLS floating client

[Jan Bramkamp]

On 20.03.20 20:45, John-Mark Gurney wrote:
> Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100:
>> On 20.03.20 02:44, Russell L. Carter wrote:
>>> Here I commit heresy, by A) top posting, and B) by just saying, why
>>> not make it easy, first, to tunnel NFSv4 sessions through
>>> e.g. net/wireguard or sysutils/spiped?  NFS is point to point.
>>> Security infrastructure that actually works understands the shared
>>> secret model.
> VPN tunneling doesn't provide the security that most people thinks it
> does...  It requires complicated configuration, and often doesn't
> provide e2e protections.
I fully agree that IPsec is a bitch to configure, but IPsec tranport 
mode between NFSv4 client and server would provide end to end encryption.
>> Why not use IPsec in transport mode instead of a tunnel? It avoids
>> unnecessary overhead and is already implemented in the kernel. It should
>> be enough to "just" require IPsec for TCP port 2049 and run a suitable
>> key exchange daemon.
> Because IPsec is a PITA to configure and work, and lots of consumer OSes
> don't make it at all easy.
Does any consumer OS support NFSv4 over TLS?
> Also, you forget that FreeBSD has ktls, which usees the same crypto
> offload engine that IPsec does, so it will effectively have similar
> overhead, and might actually perform better due to TLS having a 16k
> record encryption size vs IPsec limiting itself to packet size, usually
> 1500, though possibly 9k if you're using jumbo frames...
I compared IPsec to userspace tunnels like spiped or wireguard-go not 
kTLS. If kTLS can use LRO/TSO etc. it would avoid even more overhead.
> I fully support doing NFS over TLS.
I would love to run NFS over TLS, but it isn't implemented yet and afaik 
kTLS only accelerates TLS sending and would require a userspace proxy to 
receive TLS at the moment while IPsec transport mode is just a nasty 
fight with strongSwan away.