netdev - Re: [RFC net-next 01/15] psp: add documentation

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]

Date: Thu, 27 Jun 2024 11:14:39 -0400
From: Lance Richardson <rlance@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Willem de Bruijn <willemdebruijn.kernel@...il.com>, netdev@...r.kernel.org, 
	pabeni@...hat.com, borisp@...dia.com, gal@...dia.com, cratiu@...dia.com, 
	rrameshbabu@...dia.com, steffen.klassert@...unet.com, tariqt@...dia.com
Subject: Re: [RFC net-next 01/15] psp: add documentation

On Wed, May 29, 2024 at 1:35 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Sun, 12 May 2024 21:24:23 -0400 Willem de Bruijn wrote:

... snip ...

> > Connection key rotation is not supported? I did notice that tx key
> > insertion fails if a key is already present, so this does appear to be
> > the behavior.
>
> Correct, for now connections need to be re-established once a day.
> Rx should be easy, Tx we can make easy by only supporting rotation
> when there's no data queued.
>

Could you elaborate on why updating the Tx key should only be allowed when
no data is queued? At the point rekeying is being done, the receiver should
accept both the new and previous key:spi.

The lack of support for rekeying existing connections is a significant gap. At
a minimum the API for notifying the application that a rotation has occurred
should be defined, and the implementation should allow the configuration
of a new Tx key:spi for rekeying. A tiny bit logic would also be needed on the
Rx side to track the current and previous SPI, if the hardware supports keys
indescriptors then nothing more should be needed on the Tx side. If the NIC
maintains an SA database and doesn't allow existing entries to be updated,
a small amount of additional logic would be needed, but perhaps that could
be (waving hands a bit) the responsibility of the driver.

   - Lance