| Message ID | cover.1673952268.git.sd@queasysnail.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | tls: implement key updates for TLS1.3 | expand |
Please CC all the maintainers. 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 -
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 -
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 -
On 19/01/2023 4:55, 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 -
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 -
On Thu, 19 Jan 2023 16:40:39 +0100 Sabrina Dubroca wrote: > > > 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? I believe so, yes, just open a new connection. TLS rekeying seems to be extremely rare. You mentioned nbd as a potential use case for kernel SW implementation. Can nbd rekey? Is use space responding to control messages in case of nbd?
> 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 -
On 19.01.2023 02:55, 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 -
On 19/01/2023 10:27, Gal Pressman wrote: > On 19/01/2023 4:55, 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 -
(adding Simo and Daiki for the OpenSSL/GnuTLS sides) 2023-01-23, 10:13:58 +0000, Boris Pismenny wrote: > On 19/01/2023 10:27, Gal Pressman wrote: > > On 19/01/2023 4:55, 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 -
> 2023-01-23, 10:13:58 +0000, Boris Pismenny wrote: > > On 19/01/2023 10:27, Gal Pressman wrote: > > > On 19/01/2023 4:55, 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 -
On Wed, 25 Jan 2023 10:47:20 -0800 Apoorv Kothari wrote: > > We'll need to keep the old key around until we know all the records > > using it have been fully received, right? And that could be multiple > > old keys, in case of a quick series of key updates. > > Why does the hardware implementation need to store old keys? Does the need > for retransmitted data assume we are operating in TLS_HW_RECORD mode and > the hardware is also implementing the TCP stack? We're talking about the Tx direction, the packets are queued to the lower layers of the stack unencrypted, and get encrypted by the NIC. Until TCP gets acks for all the data awaiting offloaded crypto - we must hold onto the keys. Rx direction is much simpler indeed. > The TLS RFC assumes that the underlying transport layer provides reliable > and in-order deliver so storing previous keys and encrypting 'old' data > would be quite divergent from normal TLS behavior. Is the TLS_HW_RECORD mode > processing TLS records out of order? If the hardware offload is handling > the TCP networking stack then I feel it should also handle the > retransmission of lost data. Ignore TLS_HW_RECORD, it's a ToE offload, the offload we care about just offloads encryption.
On Wed, 2023-01-25 at 10:57 -0800, Jakub Kicinski wrote: > On Wed, 25 Jan 2023 10:47:20 -0800 Apoorv Kothari wrote: > > > We'll need to keep the old key around until we know all the records > > > using it have been fully received, right? And that could be multiple > > > old keys, in case of a quick series of key updates. > > > > Why does the hardware implementation need to store old keys? Does the need > > for retransmitted data assume we are operating in TLS_HW_RECORD mode and > > the hardware is also implementing the TCP stack? > > We're talking about the Tx direction, the packets are queued to the > lower layers of the stack unencrypted, and get encrypted by the NIC. > Until TCP gets acks for all the data awaiting offloaded crypto - we > must hold onto the keys. Is this because the NIC does not cache the already encrypted outgoing packets? If that is the case is it _guaranteed_ that the re-encrypted packets are exactly identical to the previously sent ones? If it is not guaranteed, are you blocking use of AES GCM and any other block cipher that may have very bad failure modes in a situation like this (in the case of AES GCM I am thinking of IV reuse) ? > > Rx direction is much simpler indeed. > > > The TLS RFC assumes that the underlying transport layer provides reliable > > and in-order deliver so storing previous keys and encrypting 'old' data > > would be quite divergent from normal TLS behavior. Is the TLS_HW_RECORD mode > > processing TLS records out of order? If the hardware offload is handling > > the TCP networking stack then I feel it should also handle the > > retransmission of lost data. > > Ignore TLS_HW_RECORD, it's a ToE offload, the offload we care about > just offloads encryption. >
On Wed, 25 Jan 2023 16:17:26 -0500 Simo Sorce wrote: > > We're talking about the Tx direction, the packets are queued to the > > lower layers of the stack unencrypted, and get encrypted by the NIC. > > Until TCP gets acks for all the data awaiting offloaded crypto - we > > must hold onto the keys. > > Is this because the NIC does not cache the already encrypted outgoing > packets? NIC can't cache outgoing packets, there's too many and NIC is supposed to only do crypto. TCP stack is responsible for handing rtx. > If that is the case is it _guaranteed_ that the re-encrypted packets > are exactly identical to the previously sent ones? In terms of payload, yes. Modulo zero-copy cases we don't need to get into. > If it is not guaranteed, are you blocking use of AES GCM and any other > block cipher that may have very bad failure modes in a situation like > this (in the case of AES GCM I am thinking of IV reuse) ? I don't know what you mean.
On Wed, 2023-01-25 at 14:43 -0800, Jakub Kicinski wrote: > On Wed, 25 Jan 2023 16:17:26 -0500 Simo Sorce wrote: > > > We're talking about the Tx direction, the packets are queued to the > > > lower layers of the stack unencrypted, and get encrypted by the NIC. > > > Until TCP gets acks for all the data awaiting offloaded crypto - we > > > must hold onto the keys. > > > > Is this because the NIC does not cache the already encrypted outgoing > > packets? > > NIC can't cache outgoing packets, there's too many and NIC is supposed > to only do crypto. TCP stack is responsible for handing rtx. > > > If that is the case is it _guaranteed_ that the re-encrypted packets > > are exactly identical to the previously sent ones? > > In terms of payload, yes. Modulo zero-copy cases we don't need to get > into. > > > If it is not guaranteed, are you blocking use of AES GCM and any other > > block cipher that may have very bad failure modes in a situation like > > this (in the case of AES GCM I am thinking of IV reuse) ? > > I don't know what you mean. The question was if there is *any* case where re-transmission can cause different data to be encrypted with the same key + same IV Simo.
On Wed, 25 Jan 2023 18:05:38 -0500 Simo Sorce wrote: > > > If it is not guaranteed, are you blocking use of AES GCM and any other > > > block cipher that may have very bad failure modes in a situation like > > > this (in the case of AES GCM I am thinking of IV reuse) ? > > > > I don't know what you mean. > > The question was if there is *any* case where re-transmission can cause > different data to be encrypted with the same key + same IV Not in valid use cases. With zero-copy / sendfile Tx technically the page from the page cache can change between tx and rtx, but the user needs to opt in explicitly acknowledging the application will prevent this from happening. If they don't opt-in we'll copy the data.
On Wed, 2023-01-25 at 15:08 -0800, Jakub Kicinski wrote: > On Wed, 25 Jan 2023 18:05:38 -0500 Simo Sorce wrote: > > > > If it is not guaranteed, are you blocking use of AES GCM and any other > > > > block cipher that may have very bad failure modes in a situation like > > > > this (in the case of AES GCM I am thinking of IV reuse) ? > > > > > > I don't know what you mean. > > > > The question was if there is *any* case where re-transmission can cause > > different data to be encrypted with the same key + same IV > > Not in valid use cases. With zero-copy / sendfile Tx technically > the page from the page cache can change between tx and rtx, but > the user needs to opt in explicitly acknowledging the application > will prevent this from happening. If they don't opt-in we'll copy > the data. Uhmm is there a way to detect this happening and abort further crypto operations in case it happens ? Simo.
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. 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. [1] https://www.rfc-editor.org/rfc/rfc8446#section-4.6.3 [2] https://gitlab.com/gnutls/gnutls/-/merge_requests/1625 Sabrina Dubroca (5): tls: remove tls_context argument from tls_set_sw_offload tls: block decryption when a rekey is pending tls: implement rekey for TLS1.3 selftests: tls: add key_generation argument to tls_crypto_info_init selftests: tls: add rekey tests include/net/tls.h | 4 + net/tls/tls.h | 3 +- net/tls/tls_device.c | 2 +- net/tls/tls_main.c | 32 +++- net/tls/tls_sw.c | 169 +++++++++++++++---- tools/testing/selftests/net/tls.c | 272 +++++++++++++++++++++++++++++- 6 files changed, 434 insertions(+), 48 deletions(-)