Thread (42 messages) 42 messages, 9 authors, 2022-07-13

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

From: Chuck Lever III <hidden>
Date: 2022-04-28 21:54:26
Also in: linux-cifs, linux-fsdevel, linux-nfs, linux-nvme

On Apr 28, 2022, at 5:08 PM, Jakub Kicinski [off-list ref] wrote:

On Thu, 28 Apr 2022 01:29:10 +0000 Chuck Lever III wrote:
quoted
quoted
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.

quoted
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


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help