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]
Message-ID: <1da873f4-7d9b-1bb3-0c44-0c04923bf3ab@nohats.ca>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ