netdev - Re: [PATCH net-next 0/9] psp: support rekeying psp protected tcp connections

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <willemdebruijn.kernel.37bf21c78aadd@gmail.com>
Date: Wed, 04 Feb 2026 15:45:54 -0500
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Daniel Zahka <daniel.zahka@...il.com>, 
 "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Paolo Abeni <pabeni@...hat.com>, 
 Simon Horman <horms@...nel.org>, 
 Donald Hunter <donald.hunter@...il.com>, 
 Boris Pismenny <borisp@...dia.com>, 
 Saeed Mahameed <saeedm@...dia.com>, 
 Leon Romanovsky <leon@...nel.org>, 
 Tariq Toukan <tariqt@...dia.com>, 
 Mark Bloch <mbloch@...dia.com>, 
 Andrew Lunn <andrew+netdev@...n.ch>, 
 Shuah Khan <shuah@...nel.org>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: netdev@...r.kernel.org, 
 linux-kselftest@...r.kernel.org, 
 Daniel Zahka <daniel.zahka@...il.com>
Subject: Re: [PATCH net-next 0/9] psp: support rekeying psp protected tcp
 connections

Daniel Zahka wrote:
> The PSP architecture spec specifies the need for rekeying connections
> in the event of a device key rotation. After a device key rotation has
> occurred, a new rx derived key needs to be generated and sent out to
> the other end of the connection sometime before the next device key
> rotation occurs.
> 
> Because PSP connections involve two different keys at each endpoint,
> one for decrypting ingress traffic, and one for encrypting egress
> traffic, there are two types of rekeying events that need to be
> supported. From the perspective of one endpoint of the connection:
> 
> 1. rx rekey: we need to allocate a new spi and decryption key on the
> current device key to provide to our peer.
> 
> 2. tx rekey: our peer has provided us with a new spi + encryption key
> pair which we should use for encrypting traffic immediately.
> 
> In the case of rx rekeying, there is a period where it makes sense to
> accept packets authenticated from either the previous or current
> spi. To deal with that we allow a socket to keep a chain of a max of
> two psp assocs at any time. If authentication state does not match the
> most recent assoc, the previous one will be tried.
> 
> In the case of tx rekeying, as soon as we install the new tx key, we
> have no use for the previous one, and it can be disposed of
> immediately.

So this defines a rekey event as an instant in time. An alternative
choice is to rekey at a specific seqno.

The difference matters only for retransmits.

Not sure there is a strong reason for either. But probably good to
state the choice explicitly.

> The only catch, is in the case where hw uses a key handle
> in tx descriptor state (as opposed to inlining the key directly). If
> this is the case, psp core needs to be sure that any of these
> unaccounted for references to key state are gone by the time it tries
> to sync a deleted key to hw.
> 
> To deal with this race condition, the series includes a driver api for
> implementing deferred tx key deletion, where the driver can signal
> back to the core when it is safe to dispose of old tx keys.
> 
> Lastly, some test cases for rekeying are included that go through key
> rotations and rekeying.

Still reading the code, first pass only.