On 22.05.2024 14:56, Paul Wouters wrote:

External email: Use caution opening links or attachments


Jakub Kicinski wrote:

quoted

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.

quoted

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