Re: Question regarding TLS Key update for NVMe-TCP protocol

[Sabrina Dubroca <sd@queasysnail.net>]

2024-12-03, 16:20:12 +0100, Hannes Reinecke wrote:
> On 12/3/24 15:33, Chuck Lever III wrote:
> > > On Dec 3, 2024, at 2:17 AM, Hannes Reinecke <hare@suse.de> wrote:
> > > But the current in-kernel TLS implementation doesn't allow to change
> > > the cipher ( cf net/tls/tls_main.c: do_tls_setsockopt_conf() ), so
> > > the only chance here is to close the connection and start from scratch.
> > 
> > Have we asked Boris and friends if it would be possible to
> > implement KeyUpdate via ktls? Just curious.
> > 
> The immediate problem with KeyUpdate is here:
> 
> net/tls/tls_main.c:tls_setsockopt_conf()
> 
>         /* Currently we don't support set crypto info more than one time */
>         if (TLS_CRYPTO_INFO_READY(crypto_info))
>                 return -EBUSY;

And my patches (mentioned in the first email of this thread, but
there's another version that I sent for review more recently [1])
address that.

[1] https://lore.kernel.org/netdev/cover.1731597571.git.sd@queasysnail.net/

> so we need to close the socket whenever we want to change the TLS key.
> And that results in a call to the socket callbacks, which informs the
> NVMe-TCP driver, and the connect is reset.
> 
> KeyUpdate is a single message in the packet stream, transferring
> the new key values encrypted with the original key.

nit: the KeyUpdate message doesn't contain the new key, it just says
that the new key will be used from that point on (otherwise we
wouldn't have to worry about keeping secrets around?).

> But: The new key is derived from the application secret, which is _not_ the
> currently used Key/IV values used by the in-kernel TLS implementation (cf
> section 7.3 'Traffic Key Calculation' in RFC 8446).
> So we cannot compute the next set of application traffic secrets; the only
> one who might have had this is the tlshd session, but that is destroyed once
> the handshake is done (or, rather, I hope it is ...).
> 
> So the original handshake traffic secrets are gone, and we cannot
> derive the next set of traffic secrets from there. Plus I'm not sure
> if we should keep that around in tlshd; that definitely would be prone
> to leak secret material, inviting $RANDOM_HACKER to attack tlshd ...
> 
> And that's before even checking whether we need to modify gnutls
> for deriving updated traffic secrets ...

I would expect all TLS libraries keep those secrets around to be able
to implement KeyUpdate regardless of ktls (but I only work on the
kernel, not gnutls/openssl).

-- 
Sabrina