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]

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

On 22.05.2024 14:56, Paul Wouters wrote:
> External email: Use caution opening links or attachments
>
>
> 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 ?


This has nothing to do with it.


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

Boris