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;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Boris Pismenny <borispismenny@gmail.com>
CC:     Alexander Krizhanovsky <ak@tempesta-tech.com>,
        Simo Sorce <simo@redhat.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Jakub Kicinski <kuba@kernel.org>
Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake
 listener)
Thread-Topic: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS
 handshake listener)
Thread-Index: AQHYU0RqwCfhD8h+BkiXOp6ayeNVBq0FEy8AgABugYA=
Date:   Thu, 28 Apr 2022 15:24:55 +0000
Message-ID: <33F93223-519B-47E9-8578-B18DCB8F1F8E@oracle.com>
References: <165030051838.5073.8699008789153780301.stgit@oracle-102.nfsv4.dev>
 <165030059051.5073.16723746870370826608.stgit@oracle-102.nfsv4.dev>
 <068945db-f29e-8586-0487-bb5be68c7ba8@gmail.com>
In-Reply-To: <068945db-f29e-8586-0487-bb5be68c7ba8@gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?B8qb3tYjNaFhZ2cf4PC4ALJXg5PM5qGAxqZ6DhPBjz5f6HMQuVpxz6fs7Vq5?=
 =?us-ascii?Q?g1AJWYPb1H6CcZhXaiV13aVjHRiZjZGLIr8kjDVS71VNxNZjyq8J8TAJbzPM?=
 =?us-ascii?Q?Oq15b5AN5uz/zuxVilV4P7CxRf79ZqiKPf2AkwdXQiZxgjcxnDBi+O4xn9rg?=
 =?us-ascii?Q?Mj9Mm5UL9Cgv2P31RTqo26wrFgMLAwmRTUjIE4l/b7zdBMbYf17XKbBHlhLU?=
 =?us-ascii?Q?/Z2Ap2Ff5GIIjrG5F6LllKg4oAAYnBtcbM+ZGz5Z9b05xgMEepOemglLnZDD?=
 =?us-ascii?Q?WLMgQ/YsJz374/Un6YxSBLn7qWeCl58l4eBHRBRhm/imE9cdncVk8oyEuqVu?=
 =?us-ascii?Q?VbczCGkOLLucZYgag7ADBWhCtMd346WHlWXk2AyHRY9do9NV+OFrl/d+Jv29?=
 =?us-ascii?Q?YhIRjJa7hblCVaHdLwJS0XczWSz7oj8xF7N0h24PFrDmEA8WgdfExxFK0L2/?=
 =?us-ascii?Q?3+9on+DVfsg0zwafC6HhGuNyHxJOd40wTRy+yoFTPsyoVPmQ92I1ipKhWC9S?=
 =?us-ascii?Q?a8UAaxVuis57ceintjQmAQN9xdmP05yofDVA4p0uy7+mH0O5cq+VfOCfBuT7?=
 =?us-ascii?Q?po0dZz9EGTw7RYdL1xcOaZNZacDNQQaRAdZsjTgKFEuVONBeTWfg7HQxxWDK?=
 =?us-ascii?Q?WJFSa8X5oZymT1zbVVUvu7keXtJ5sEJs6us5Dx5vMqQ+/Oqdy9M63UbkXZj0?=
 =?us-ascii?Q?PL9DheMou+8fU0vRi4S+FP6BIVppa/PsbxGf9TzlTK2op+x1mM0psWlqeudl?=
 =?us-ascii?Q?pZn+jGwgUk6eqk2rOANrVK2DR7XW06dp61S7KxslhBCXTT8mH81h180WE/ST?=
 =?us-ascii?Q?wixjv14lyjsX+rna01oT59LdfDwTszhwcCWe4ouwufNAh8X6I7IOoebxmplb?=
 =?us-ascii?Q?IksxC5SK6EjtK1pqtSftvRYi8WoaZSFCqP2qr2/ptS0pgwbl66l7a7HBTbTM?=
 =?us-ascii?Q?MpUKzOU/wy0mxIDk3btNbTbmZZ7adjY95ZUojPl6JWsp2DWsgde32euPI/X1?=
 =?us-ascii?Q?fNgyRrNlPt33FwcAnuwunroHtiJ822mzmn0/neBtkyZHU+y7adNOrcdXdG9G?=
 =?us-ascii?Q?m0Rs1+iCK4SbGIyD5cvEwTBQPEvZybuudzDVlpVZpla7jAfP0zSpEg42oYxI?=
 =?us-ascii?Q?rHGeE350KO+rqNNGWjzvsl2JDddRadbkIZzS9fN9w3LAKaVx+PV/13LCwC8J?=
 =?us-ascii?Q?JWfX42g9oJ6pxUKn8LRVE1ghAuRS/jA6efnJ6hV2boI84qRPNk2apnK6AwWL?=
 =?us-ascii?Q?OIk3CUkfOmrzTE9VakEx7rPxTUQAyy5KbGaKwK7cttMNQVZC6BQXg4PeORQy?=
 =?us-ascii?Q?ouQvILtRQGotoNqAdFchKTwbkgtr4JBkfN13LG1YDwUPDxAR7foFQopKeKoc?=
 =?us-ascii?Q?dG0MGpz1YkuwO3qACA8aJFdrLANwbTjMVB5RnthFWAVcjmPIzjtc3lmhZtFg?=
 =?us-ascii?Q?Oeors1HL7HzlwtB4qgrq0i+FD2rCLR2pYz9ydmuNEnwTeAtVVOYwMkQ1XW7g?=
 =?us-ascii?Q?c9heqFlaJ64zUrIecwU+37Q8//1jLscXwyNubTXjj0L/uvI/egnRJQYKMGMR?=
 =?us-ascii?Q?ZE9+x3aZnTJ4DU1xRSlYE3Dpbj9+QifWt2V78mhUS3E7p+CjJ2/mCmJDpl8z?=
 =?us-ascii?Q?zbPfa59dP+CNp62lP95T7QNc2jxVco+pFD0uBltmDzh9qSB+yVO4IsCRPLJ5?=
 =?us-ascii?Q?luY0QCt2lTV4FWgZvCs70px0QWvJ644ZxExJ6Il0dR7wn+o8sAZkXN2j+Vhf?=
 =?us-ascii?Q?KoLOAGRmdxkcjLj2+We1zCpAn75QA7E=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <33782C8C631E7C4A94AB466EAB495238@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 4bf1c485-6ce6-4fea-dd5f-08da292b3fcb
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2022 15:24:55.6847
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 2qy2Dm9NjeslZmUE6m5GlPENbmi3aOYmzeyZ81kkdJ7KMT3s1efLbdTXuvieP4NVjfzuqw52TQ6LqKBai31ZhA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR10MB4783
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-28_02:2022-04-28,2022-04-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0
 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2204280092
X-Proofpoint-GUID: vmr-19xb3e5L3q533INABB62X2AAiMnp
X-Proofpoint-ORIG-GUID: vmr-19xb3e5L3q533INABB62X2AAiMnp
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Apr 28, 2022, at 4:49 AM, Boris Pismenny <borispismenny@gmail.com> wro=
te:
>=20
> 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.
>>=20
>> 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.
>>=20
>> This prototype currently handles only initiating client-side TLS
>> handshakes. Server-side handshakes and key renegotiation are left
>> to do.
>>=20
>> Security Considerations
>> ~~~~~~~~ ~~~~~~~~~~~~~~
>>=20
>> This prototype is net-namespace aware.
>>=20
>> The kernel has no mechanism to attest that the listening user space
>> agent is trustworthy.
>>=20
>> Currently the prototype does not handle multiple listeners that
>> overlap -- multiple listeners in the same net namespace that have
>> overlapping bind addresses.
>>=20
>=20
> 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.
>=20
> 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/t=
ls.
> 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 the=
se.

I agree that control messages need to be handled as well. For the
moment, the prototype simply breaks the connection when a control
message is encountered, and a new session is negotiated. That of
course is not the desired long-term solution.

If we believe that control messages are going to be distinct for
each transport security layer, then perhaps we cannot make the
handshake mechanism generic -- it will have to be specific to
each security layer. Just a thought.


> 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?

Certainly piping the handshake messages up to user space instead
of handing off a socket is possible. The TLS libraries would need
to tolerate this, and GnuTLS (at least) appears OK with performing
a handshake on an AF_TLSH socket.

However, I don't see a need to outright avoid passing a connected
endpoint to user space. The only difficulty with it seems to be
that it hasn't been done before in quite this way.


--
Chuck Lever