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]

Message-ID: <20240627153347.75e544ac@kernel.org>
Date: Thu, 27 Jun 2024 15:33:47 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Lance Richardson <rlance@...gle.com>
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 Thu, 27 Jun 2024 11:14:39 -0400 Lance Richardson wrote:
> > > 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.

I didn't say it shouldn't be allowed, just that disallowing it
initially would make the implementation easier ;)

> 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, 

Notifications are in place, that's one of the reasons I chose netlink.

> and the implementation should allow the configuration of a new Tx
> key:spi for rekeying.

I was under the possibly mistaken impression that Google have used PSP
for years without rekeying... Did I misunderstand?

> 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.

Interesting. Hm. But SADB drivers would then have to implement some
complex logic to make sure all rings have cycled, or take references.
I'd rather have an opt-in for core to delay reaping old keys until
all sockets which used them went empty at least once (in wmem sense).