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-next>] [day] [month] [year] [list]

Date: Wed, 22 May 2024 08:56:02 -0400 (EDT)
From: Paul Wouters <paul@...ats.ca>
To: Jakub Kicinski <kuba@...nel.org>, netdev@...r.kernel.org
cc: pabeni@...hat.com, willemdebruijn.kernel@...il.com, borisp@...dia.com, 
    gal@...dia.com, cratiu@...dia.com, rrameshbabu@...dia.com, 
    Steffen Klassert <steffen.klassert@...unet.com>, tariqt@...dia.com, 
    Jakub Kicinski <kuba@...nel.org>
Subject: Re: [RFC net-next 00/15] add basic PSP encryption for TCP
 connections

Jakub Kicinski wrote:

> Add support for PSP encryption of TCP connections.
> 
> PSP is a protocol out of Google:
> https://github.com/google/psp/blob/main/doc/PSP_Arch_Spec.pdf
> which shares some similarities with IPsec. I added some more info
> in the first patch so I'll keep it short here.

Speaking as an IETF contributor, I am little surprised here. I know
the google people reached out at IETF and were told their stuff is
so similar to IPsec, maybe they should talk to the IPsecME Working
Group. There, I believe Steffen Klassert started working on supporting
the PSP features requested using updates to the ESP/WESP IPsec protocol,
such as support for encryption offset to reveal protocol/ports for
routing encrypted traffic.

It is not very useful to add more very similar encryption techniques to
the kernel. It scatters development efforts and actually makes it harder
for people to use functionality by having to change to a whole new sub
system (and its configuration methods) just to get one different feature
of packet encryption.

> The protocol can work in multiple modes including tunneling.
> But I'm mostly interested in using it as TLS replacement because
> of its superior offload characteristics. So this patch does three
> things:

Is this issue related to draft-pismenny-tls-dtls-plaintext-sequence-number ?

https://datatracker.ietf.org/doc/draft-pismenny-tls-dtls-plaintext-sequence-number/

If so, then it seems it would be far better to re-engage the TLS WG to
see if instead of "having no interest, do it but elsewhere", we can
convince them to "there is interest, let's do it here at the TLS WG".
I could help with the latter.

Paul