Add a manpage for kernel TLS.

[jhb]

Summary

This subsumes some of the content from tcp(4) describing the socket
options but also adds additional notes.

[gbe]

@jhb did you run the obligatory igor and mandoc -Tlint checks?

[jhb]

@gbe Hmm, igor was happy, but mandoc found a couple of nits. tcp.4 has many other existing mandoc complaints but I will let those be.

[jhb]

• Fix a few nits reported by mandoc.

[rmacklem]

Thanks for doing this John. A couple of typo comments are inline.
Have you thought about how to configure this at boot time?
(I emailed you a little rc.d script. The nfs-over-tls daemons start
via rc.d scripts and need it configured.

What do you think?
(I can put it on phabricator if you'd prefer that?)

head/share/man/man4/ktls.4

81 ↗

(On Diff #80008)

spelling of "performed"

87 ↗

(On Diff #80008)

"is" doesn't seem to be needed and makes it difficult to read?

[rmacklem]

I am now thinking that the ktls script is not needed
and is just one more thing to maintain.
/boot/loader.conf for loading modules and /etc/sysctl.conf
for syscyls seems sufficient to me.

I'll leave it up to you.

[jhb]

In D27272#611922, @rmacklem wrote:

I am now thinking that the ktls script is not needed
and is just one more thing to maintain.
/boot/loader.conf for loading modules and /etc/sysctl.conf
for syscyls seems sufficient to me.

I'll leave it up to you.

I think we can just let people set settings in sysctl.conf. However, it might also make sense to flip the default settings in a KERN_TLS kernel to enable unmapped mbufs and ktls by default. Since KERN_TLS is not in GENERIC, it's already an opt-in thing.

[rmacklem]

It's up to you, however I tend to think of sysctls as orthogonal
to kernel options and, as such, having the default change
based on KERN_TLS seems a little weird to me.

I can see a case where a sysadmin has a large # of systems,
a few of which use ktls, but they use the same custom kernel
for all of the systems. They might not prefer this change in defaults.

Although I don't think you'd want to do so now, is there a
reason that KERN_TLS cannot be in GENERIC in the future?

[jhb]

In D27272#613155, @rmacklem wrote:

It's up to you, however I tend to think of sysctls as orthogonal
to kernel options and, as such, having the default change
based on KERN_TLS seems a little weird to me.

I can see a case where a sysadmin has a large # of systems,
a few of which use ktls, but they use the same custom kernel
for all of the systems. They might not prefer this change in defaults.

Although I don't think you'd want to do so now, is there a
reason that KERN_TLS cannot be in GENERIC in the future?

The reason it is off today is probably more due to excessive paranoia
and it being a new feature. Most other optional features default to
on when enabled (e.g. 'options IPSEC' or 'options NFSCL').

It probably should flip to default to on once it is considered
non-experimental (and I think we are probably at that point).

In regards to adding it to GENERIC, I'm not quite sure about that one.

[rmacklem]

Righto. I was thinking that, someday (maybe within the
FreeBSD13 release lifetime) that NFS over TLS might
become widely useful and not needing to build a
custom kernel would be nice then.

I was thinking there might have been a reason,
such a export issues w.r.t encryption, that would
make the answer "never" to putting it in GENERIC.

Btw, all the kernel bits for NFS over TLS are now in
head/FreeBSD13 and I have created a port for the
daemons that depends on the security/openssl-devel
port. (I have asked the openssl-devel port maintainer
if KTLS can be enabled by default on it.)

Obviously, I'm just trying to make NFS over TLS easier to set up
on FreeBSD13.

Thanks for the comments, rick