Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <068945db-f29e-8586-0487-bb5be68c7ba8@gmail.com>
Date:   Thu, 28 Apr 2022 11:49:24 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake
 listener)
Content-Language: en-US
To:     Chuck Lever <chuck.lever@oracle.com>
Cc:     ak@tempesta-tech.com, simo@redhat.com,
        linux-fsdevel@vger.kernel.org, linux-cifs@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-nvme@lists.infradead.org,
        netdev@vger.kernel.org, Jakub Kicinski <kuba@kernel.org>
References: <165030051838.5073.8699008789153780301.stgit@oracle-102.nfsv4.dev>
 <165030059051.5073.16723746870370826608.stgit@oracle-102.nfsv4.dev>
From:   Boris Pismenny <borispismenny@gmail.com>
In-Reply-To: <165030059051.5073.16723746870370826608.stgit@oracle-102.nfsv4.dev>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 18/04/2022 19:49, Chuck Lever wrote:
> In-kernel TLS consumers need a way to perform a TLS handshake. In
> the absence of a handshake implementation in the kernel itself, a
> mechanism to perform the handshake in user space, using an existing
> TLS handshake library, is necessary.
>
> I've designed a way to pass a connected kernel socket endpoint to
> user space using the traditional listen/accept mechanism. accept(2)
> gives us a well-understood way to materialize a socket endpoint as a
> normal file descriptor in a specific user space process. Like any
> open socket descriptor, the accepted FD can then be passed to a
> library such as openSSL to perform a TLS handshake.
>
> This prototype currently handles only initiating client-side TLS
> handshakes. Server-side handshakes and key renegotiation are left
> to do.
>
> Security Considerations
> ~~~~~~~~ ~~~~~~~~~~~~~~
>
> This prototype is net-namespace aware.
>
> The kernel has no mechanism to attest that the listening user space
> agent is trustworthy.
>
> Currently the prototype does not handle multiple listeners that
> overlap -- multiple listeners in the same net namespace that have
> overlapping bind addresses.
>

Thanks for posting this. As we discussed offline, I think this approach
is more manageable compared to a full in-kernel TLS handshake. A while
ago, I've hacked around TLS to implement the data-path for NVMe-TLS and
the data-path is indeed very simple provided an infrastructure such as
this one.

Making this more generic is desirable, and this obviously requires
supporting multiple listeners for multiple protocols (TLS, DTLS, QUIC,
PSP, etc.), which suggests that it will reside somewhere outside of net/tls.
Moreover, there is a need to support (TLS) control messages here too.
These will occasionally require going back to the userspace daemon
during kernel packet processing. A few examples are handling: TLS rekey,
TLS close_notify, and TLS keepalives. I'm not saying that we need to
support everything from day-1, but there needs to be a way to support these.

A related kernel interface is the XFRM netlink where the kernel asks a
userspace daemon to perform an IKE handshake for establishing IPsec SAs.
This works well when the handshake runs on a different socket, perhaps
that interface can be extended to do handshakes on a given socket that
lives in the kernel without actually passing the fd to userespace. If we
avoid instantiating a full socket fd in userspace, then the need for an
accept(2) interface is reduced, right?