From: Jakub Kicinski <email@example.com> To: Chuck Lever III <firstname.lastname@example.org> Cc: netdev <email@example.com>, Linux NFS Mailing List <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org> Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Date: Thu, 28 Apr 2022 14:08:51 -0700 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <F64C2771-663D-4BE7-9EB9-A8859818C7F8@oracle.com> 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. > whether the IV implantation was successful. I'm used to IV meaning Initialization Vector in context of crypto, what does "IV implementation" stand for? > So instead of an AF_TLSH listener we could use a named pipe or a > netlink socket and a blocking recv(), as long as there is a reasonable > solution to how a connected socket fd is attached to the handshake > agent process. > > I'm flexible about the mechanism for passing handshake parameters. > Attaching them to the connected socket seems convenient, but perhaps > not aesthetic. recv()-based version would certainly make me happy.
next prev parent reply other threads:[~2022-04-28 21:08 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-18 16:49 [PATCH RFC 0/5] Implement a TLS handshake upcall Chuck Lever 2022-04-18 16:49 ` [PATCH RFC 1/5] net: Add distinct sk_psock field Chuck Lever 2022-04-21 7:35 ` Hannes Reinecke 2022-07-13 4:46 ` Hawkins Jiawei 2022-07-13 4:46 ` Hawkins Jiawei 2022-04-18 16:49 ` [PATCH RFC 2/5] tls: build proto after context has been initialized Chuck Lever 2022-04-25 17:11 ` Jakub Kicinski 2022-04-25 17:51 ` Chuck Lever III 2022-05-20 16:39 ` Chuck Lever III 2022-04-18 16:49 ` [PATCH RFC 3/5] net/tls: Add an AF_TLSH address family Chuck Lever 2022-04-21 7:35 ` Hannes Reinecke 2022-04-18 16:49 ` [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Chuck Lever 2022-04-21 7:36 ` Hannes Reinecke 2022-04-25 17:14 ` Jakub Kicinski 2022-04-26 9:43 ` Hannes Reinecke 2022-04-26 14:29 ` Sagi Grimberg 2022-04-26 15:02 ` Jakub Kicinski 2022-04-26 15:58 ` Hannes Reinecke 2022-04-27 0:03 ` Jakub Kicinski 2022-04-27 15:24 ` Chuck Lever III 2022-04-28 7:26 ` Hannes Reinecke 2022-04-28 13:30 ` Jakub Kicinski 2022-04-28 13:51 ` Hannes Reinecke 2022-04-28 14:09 ` Benjamin Coddington 2022-04-28 21:08 ` Jakub Kicinski 2022-05-24 10:05 ` [ovs-dev] " Ilya Maximets 2022-04-26 14:55 ` Jakub Kicinski 2022-04-26 13:48 ` Chuck Lever III 2022-04-26 14:55 ` Jakub Kicinski 2022-04-26 15:58 ` Chuck Lever III 2022-04-26 23:47 ` Jakub Kicinski 2022-04-27 14:42 ` Chuck Lever III 2022-04-27 23:53 ` Jakub Kicinski 2022-04-28 1:29 ` Chuck Lever III 2022-04-28 21:08 ` Jakub Kicinski [this message] 2022-04-28 21:54 ` Chuck Lever III 2022-04-28 8:49 ` Boris Pismenny 2022-04-28 13:12 ` Simo Sorce 2022-04-29 15:19 ` Chuck Lever III 2022-04-28 15:24 ` Chuck Lever III 2022-04-29 6:25 ` Hannes Reinecke 2022-04-18 16:49 ` [PATCH RFC 5/5] net/tls: Add observability for AF_TLSH sockets Chuck Lever 2022-04-21 7:36 ` Hannes Reinecke
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.