From: Sabrina Dubroca <sd@queasysnail.net>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, Frantisek Krenzelok <fkrenzel@redhat.com>
Subject: Re: [PATCH net-next 0/5] tls: implement key updates for TLS1.3
Date: Wed, 18 Jan 2023 11:06:25 +0100 [thread overview]
Message-ID: <Y8fEodSWeJZyp+Sh@hog> (raw)
In-Reply-To: <20230117180351.1cf46cb3@kernel.org>
2023-01-17, 18:03:51 -0800, Jakub Kicinski wrote:
> Please CC all the maintainers.
Sorry.
> 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.
> > 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 <fkrenzel@redhat.com> 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.
IIRC support for KeyUpdates is mandatory in TLS1.3, so currently the
kernel can't claim to support 1.3, independent of offloading.
Some folks did tests with and without kTLS using nbdcopy and found a
small but noticeable performance improvement (around 8-10%).
> > Note: in a future series, I'll clean up tls_set_sw_offload and
> > eliminate the per-cipher copy-paste using tls_cipher_size_desc.
>
> Yeah, I think it's on Vadim's TODO list as well.
I've already done most of the work as I was working on this, I'll
submit it later.
--
Sabrina
next prev parent reply other threads:[~2023-01-18 11:03 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-17 13:45 [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Sabrina Dubroca
2023-01-17 13:45 ` [PATCH net-next 1/5] tls: remove tls_context argument from tls_set_sw_offload Sabrina Dubroca
2023-01-18 23:12 ` Vadim Fedorenko
2023-01-17 13:45 ` [PATCH net-next 2/5] tls: block decryption when a rekey is pending Sabrina Dubroca
2023-01-19 2:10 ` [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Apoorv Kothari
2023-01-17 13:45 ` [PATCH net-next 3/5] tls: implement rekey " Sabrina Dubroca
2023-01-17 23:16 ` Kuniyuki Iwashima
2023-01-18 10:38 ` Sabrina Dubroca
2023-01-19 1:25 ` Apoorv Kothari
2023-01-19 15:16 ` Sabrina Dubroca
2023-01-18 23:10 ` Vadim Fedorenko
2023-01-19 15:14 ` Sabrina Dubroca
2023-01-17 13:45 ` [PATCH net-next 4/5] selftests: tls: add key_generation argument to tls_crypto_info_init Sabrina Dubroca
2023-01-17 13:45 ` [PATCH net-next 5/5] selftests: tls: add rekey tests Sabrina Dubroca
2023-01-20 6:51 ` Apoorv Kothari
2023-01-18 2:03 ` [PATCH net-next 0/5] tls: implement key updates for TLS1.3 Jakub Kicinski
2023-01-18 10:06 ` Sabrina Dubroca [this message]
2023-01-19 2:55 ` Jakub Kicinski
2023-01-19 9:27 ` Gal Pressman
2023-01-23 10:13 ` Boris Pismenny
2023-01-24 15:56 ` Sabrina Dubroca
2023-01-25 18:47 ` Apoorv Kothari
2023-01-25 18:57 ` Jakub Kicinski
2023-01-25 21:17 ` Simo Sorce
2023-01-25 22:43 ` Jakub Kicinski
2023-01-25 23:05 ` Simo Sorce
2023-01-25 23:08 ` Jakub Kicinski
2023-01-25 23:52 ` Simo Sorce
2023-01-19 15:40 ` Sabrina Dubroca
2023-01-19 17:00 ` Jakub Kicinski
2023-01-19 20:51 ` Apoorv Kothari
2023-01-20 1:37 ` Vadim Fedorenko
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 \
--in-reply-to=Y8fEodSWeJZyp+Sh@hog \
--to=sd@queasysnail.net \
--cc=fkrenzel@redhat.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).