| Message ID | cover.1734013874.git.sd@queasysnail.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | tls: implement key updates for TLS1.3 | expand |
Hello: This series was applied to netdev/net-next.git (main) by David S. Miller <davem@davemloft.net>: On Thu, 12 Dec 2024 16:36:03 +0100 you 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 > 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 > > [...] Here is the summary with links: - [net-next,v5,1/6] tls: block decryption when a rekey is pending https://git.kernel.org/netdev/net-next/c/0471b1093e3a - [net-next,v5,2/6] tls: implement rekey for TLS1.3 https://git.kernel.org/netdev/net-next/c/47069594e67e - [net-next,v5,3/6] tls: add counters for rekey https://git.kernel.org/netdev/net-next/c/510128b30f2d - [net-next,v5,4/6] docs: tls: document TLS1.3 key updates https://git.kernel.org/netdev/net-next/c/5aa97a43d042 - [net-next,v5,5/6] selftests: tls: add key_generation argument to tls_crypto_info_init https://git.kernel.org/netdev/net-next/c/b2e584aa3c71 - [net-next,v5,6/6] selftests: tls: add rekey tests https://git.kernel.org/netdev/net-next/c/555f0edb9ff0 You are awesome, thank you!
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 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. ======================================================================= Discussions around v2 of this patchset focused on how HW offload would interact with rekey. RX - The existing SW path will handle all records between the KeyUpdate message signaling the change of key and the new key becoming known to the kernel -- those will be queued encrypted, and decrypted in SW as they are read by userspace (once the key is provided, ie same as this patchset) - Call ->tls_dev_del + ->tls_dev_add immediately during setsockopt(TLS_RX) TX - After setsockopt(TLS_TX), switch to the existing SW path (not the current device_fallback) until we're able to re-enable HW offload - tls_device_sendmsg will call into tls_sw_sendmsg under lock_sock to avoid changing socket ops during the rekey while another thread might be waiting on the lock - We only re-enable HW offload (call ->tls_dev_add to install the new key in HW) once all records sent with the old key have been ACKed. At this point, all unacked records are SW-encrypted with the new key, and the old key is unused by both HW and retransmissions. - If there are no unacked records when userspace does setsockopt(TLS_TX), we can (try to) install the new key in HW immediately. - If yet another key has been provided via setsockopt(TLS_TX), we don't install intermediate keys, only the latest. - TCP notifies ktls of ACKs via the icsk_clean_acked callback. In case of a rekey, tls_icsk_clean_acked will record when all data sent with the most recent past key has been sent. The next call to sendmsg will install the new key in HW. - We close and push the current SW record before reenabling offload. If ->tls_dev_add fails to install the new key in HW, we stay in SW mode. We can add a counter to keep track of this. In addition: Because we can't change socket ops during a rekey, we'll also have to modify do_tls_setsockopt_conf to check ctx->tx_conf and only call either tls_set_device_offload or tls_set_sw_offload. RX already uses the same ops for both TLS_HW and TLS_SW, so we could switch between HW and SW mode on rekey. An alternative would be to have a common sendmsg which locks the socket and then calls the correct implementation. We'll need that anyway for the offload under rekey case, so that would only add a test to the SW path's ops (compared to the current code). That should allow us to simplify build_protos a bit, but might have a performance impact - we'll need to check it if we want to go that route. ======================================================================= Changes since v4: - add counter for received KeyUpdate messages - improve wording in the documentation - improve handling of bogus messages when looking for KeyUpdate's - some coding style clean ups Changes since v3: - rebase on top of net-next - rework tls_check_pending_rekey according to Jakub's feedback - add statistics for rekey: {RX,TX}REKEY{OK,ERROR} - some coding style clean ups Link: https://lore.kernel.org/netdev/cover.1731597571.git.sd@queasysnail.net/ [v4] Link: https://lore.kernel.org/netdev/cover.1691584074.git.sd@queasysnail.net/ [v3] Link: https://lore.kernel.org/netdev/cover.1676052788.git.sd@queasysnail.net/ [v2] Link: https://lore.kernel.org/netdev/cover.1673952268.git.sd@queasysnail.net/ [v1] Link: https://www.rfc-editor.org/rfc/rfc8446#section-4.6.3 [1] Link: https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 [2] Sabrina Dubroca (6): tls: block decryption when a rekey is pending tls: implement rekey for TLS1.3 tls: add counters for rekey docs: tls: document TLS1.3 key updates selftests: tls: add key_generation argument to tls_crypto_info_init selftests: tls: add rekey tests Documentation/networking/tls.rst | 36 +++ include/net/tls.h | 3 + include/uapi/linux/snmp.h | 5 + net/tls/tls.h | 3 +- net/tls/tls_device.c | 2 +- net/tls/tls_main.c | 71 ++++- net/tls/tls_proc.c | 5 + net/tls/tls_sw.c | 140 ++++++--- tools/testing/selftests/net/tls.c | 478 +++++++++++++++++++++++++++++- 9 files changed, 682 insertions(+), 61 deletions(-)