From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B39F7C004D4 for ; Thu, 19 Jan 2023 15:43:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230432AbjASPng convert rfc822-to-8bit (ORCPT ); Thu, 19 Jan 2023 10:43:36 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43862 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230029AbjASPnf (ORCPT ); Thu, 19 Jan 2023 10:43:35 -0500 Received: from us-smtp-delivery-44.mimecast.com (unknown [207.211.30.44]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 21BBD4941F for ; Thu, 19 Jan 2023 07:43:33 -0800 (PST) Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-645-3RP3imIXPzmOVXGpWVfo3Q-1; Thu, 19 Jan 2023 10:42:38 -0500 X-MC-Unique: 3RP3imIXPzmOVXGpWVfo3Q-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 6EC411C189AB; Thu, 19 Jan 2023 15:42:11 +0000 (UTC) Received: from hog (unknown [10.39.192.162]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EDBE01415108; Thu, 19 Jan 2023 15:42:09 +0000 (UTC) Date: Thu, 19 Jan 2023 16:40:39 +0100 From: Sabrina Dubroca To: Jakub Kicinski Cc: netdev@vger.kernel.org, Frantisek Krenzelok , Gal Pressman , Apoorv Kothari Subject: Re: [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Message-ID: References: <20230117180351.1cf46cb3@kernel.org> <20230118185522.44c75f73@kernel.org> MIME-Version: 1.0 In-Reply-To: <20230118185522.44c75f73@kernel.org> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: queasysnail.net Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Content-Transfer-Encoding: 8BIT Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 2023-01-18, 18:55:22 -0800, Jakub Kicinski wrote: > On Wed, 18 Jan 2023 11:06:25 +0100 Sabrina Dubroca wrote: > > 2023-01-17, 18:03:51 -0800, Jakub Kicinski wrote: > > > On Tue, 17 Jan 2023 14:45:26 +0100 Sabrina Dubroca wrote: > > > > This adds support for receiving KeyUpdate messages (RFC 8446, 4.6.3 > > > > [1]). A sender transmits a KeyUpdate message and then changes its TX > > > > key. The receiver should react by updating its RX key before > > > > processing the next message. > > > > > > > > This patchset implements key updates by: > > > > 1. pausing decryption when a KeyUpdate message is received, to avoid > > > > attempting to use the old key to decrypt a record encrypted with > > > > the new key > > > > 2. returning -EKEYEXPIRED to syscalls that cannot receive the > > > > KeyUpdate message, until the rekey has been performed by userspace > > > > > > Why? We return to user space after hitting a cmsg, don't we? > > > If the user space wants to keep reading with the old key - 🤷️ > > > > But they won't be able to read anything. Either we don't pause > > decryption, and the socket is just broken when we look at the next > > record, or we pause, and there's nothing to read until the rekey is > > done. I think that -EKEYEXPIRED is better than breaking the socket > > just because a read snuck in between getting the cmsg and setting the > > new key. > > IDK, we don't interpret any other content types/cmsgs, and for well > behaved user space there should be no problem (right?). > I'm weakly against, if nobody agrees with me you can keep as is. I was concerned (I don't know if it's realistic) about a userspace application with two threads: Thread A Thread B -------- -------- read cmsg read some data (still on the old key) sets the new key I guess one could claim that's a userspace bug. František's implementation in gnutls doesn't seem to rely on this. Apoorv, since you were also looking into key updates, do you have an opinion on pausing decryption/reads until userspace has provides the new key? > > > > 3. passing the KeyUpdate message to userspace as a control message > > > > 4. allowing updates of the crypto_info via the TLS_TX/TLS_RX > > > > setsockopts > > > > > > > > This API has been tested with gnutls to make sure that it allows > > > > userspace libraries to implement key updates [2]. Thanks to Frantisek > > > > Krenzelok for providing the implementation in > > > > gnutls and testing the kernel patches. > > > > > > Please explain why - the kernel TLS is not faster than user space, > > > the point of it is primarily to enable offload. And you don't add > > > offload support here. > > > > Well, TLS1.3 support was added 4 years ago, and yet the offload still > > doesn't support 1.3 at all. > > I'm pretty sure some devices support it. None of the vendors could > be bothered to plumb in the kernel support, yet, tho. > I don't know of anyone supporting rekeying. > > > IIRC support for KeyUpdates is mandatory in TLS1.3, so currently the > > kernel can't claim to support 1.3, independent of offloading. > > The problem is that we will not be able to rekey offloaded connections. > For Tx it's a non-trivial problem given the current architecture. > The offload is supposed to be transparent, we can't fail the rekey just > because the TLS gotten offloaded. What's their plan when the peer sends a KeyUpdate request then? Let the connection break? -- Sabrina