netdev - Re: [RFC net-next 00/15] add basic PSP encryption for 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: <66561e53a11be_2a1fb929472@willemb.c.googlers.com.notmuch>
Date: Tue, 28 May 2024 14:11:31 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Paul Wouters <paul@...ats.ca>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Steffen Klassert <steffen.klassert@...unet.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 netdev@...r.kernel.org, 
 pabeni@...hat.com, 
 borisp@...dia.com, 
 gal@...dia.com, 
 cratiu@...dia.com, 
 rrameshbabu@...dia.com, 
 tariqt@...dia.com
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP connections

Paul Wouters wrote:
> On Tue, 28 May 2024, Willem de Bruijn wrote:
> 
> > One point about why PSP is that the exact protocol and packet format
> > is already in use and supported by hardware.
> 
> Using mostly the IPsec hw code? :)

Not necessarily.

A goal of PSP was to allow an O(1) state device implementation that
does away with the SADB. Using key derivation on Rx and keys in
descriptor on Tx.
 
> > It makes sense to work to get to an IETF standard protocol that
> > captures the same benefits. But that is independent from enabling what
> > is already implemented.
> 
> How many different packet encryption methods should the linux kernel
> have? There are good reasons to go through standard bodies. Doing your
> own thing and then saying "but we did it already" to me does not feel
> like a strong argument. That's how we got wireguard with all of its
> issues of being written for a single use case, and now being unfit for
> generic use cases.
> 
> Going through standards organizations also gains you interoperability
> with non-linux (hardware) vendors, again reducing the number of
> different mostly similar schemes that need to be supported and
> maintained for years or decades.

I don't disagree on the merits of a standards process, of course. It's
just moot at this point wrt PSP. Hardware support and some users are
here. A new packet format cannot be supported retroactively.

That said, an IETF (ESP) protocol is a potential upgrade path even for
existing users in the longer term. If we can make sure that it covers
all the key PSP features.