Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)

Chuck Lever III
2022-04-28T21:58:15Z

> On Apr 28, 2022, at 5:08 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Thu, 28 Apr 2022 01:29:10 +0000 Chuck Lever III wrote:
>>> Is it possible to instead create a fd-passing-like structured message
>>> which could carry the fd and all the relevant context (what goes
>>> via the getsockopt() now)?
>>>
>>> The user space agent can open such upcall socket, then bind to
>>> whatever entity it wants to talk to on the kernel side and read
>>> the notifications via recv()?
>>
>> We considered this kind of design. A reasonable place to start there
>> would be to fabricate new NETLINK messages to do this. I don't see
>> much benefit over what is done now, it's just a different isomer of
>> syntactic sugar, but it could be considered.
>>
>> The issue is how the connected socket is materialized in user space.
>> accept(2) is the historical way to instantiate an already connected
>> socket in a process's file table, and seems like a natural fit. When
>> the handshake agent is done with the handshake, it closes the socket.
>> This invokes the tlsh_release() function which can check
>
> Actually - is that strictly necessary? It seems reasonable for NFS to
> check that it got TLS, since that's what it explicitly asks for per
> standard. But it may not always be the goal. In large data center
> networks there can be a policy the user space agent consults to choose
> what security to install. It may end up doing the auth but not enable
> crypto if confidentiality is deemed unnecessary.

> Obviously you may not have those requirements but if we can cover them
> without extra complexity it'd be great.

We can be flexible about how/where handshake success is checked.

However, using a simple close(2) to signal that the handshake
has completed does not communicate whether the handshake was
indeed successful. We will need a (richer) return/error code
from the handshake agent for that use case.

>> whether the IV implantation was successful.
>
> I'm used to IV meaning Initialization Vector in context of crypto,
> what does "IV implementation" stand for?

Implantation, not implementation. The handshake agent implants
the initialization vector in the socket before it closes it.

--
Chuck Lever