Maybe but probably not. Various always-on , SDN, or wide scale site-to-site VPN schemes are deployed widely enough for long enough now that it's expected infrastructure at this point.

Even getting people to use certificates on IPSEC tunnels is a pain. Which reminds me, I think the smallest models of either Palo Alto or Checkpoint still have bizarre authentication failures if the certificate chain is too long, which was always weird to me because the control planes had way more memory than necessary for well over a decade.

▲

cryptonector 7 hours ago | parent [-]

You're not thinking creatively enough. I'm only interested in ESP, not IKE. Consider having the TLS handshake negotiate the use of ESP, and when selected the system would plumb ESP for this connection using keys negotiated by TLS (using the exporter). Think ktls/kssl but with ESP. Presto -- no orchestration of IKE credentials, nothing -- it should just work.

The real key is getting ESP HW offload.

▲

reincarnate0x14 7 hours ago | parent [-]

Oh I agree with it being nice, I'm just imagining more socialization oriented resistance to implementation and both large organizations and hobbyists already have answers that mostly cover the use cases even if not exactly as cleanly. Moving node to node encryption to an accelerated implementation of transport mode would be great, but if you're already using TLS I can see people just sticking in TLS versus hoping both ends had the necessary handshake->ESP path working, plus people are more experienced with existing troubleshooting, etc.

	▲	cryptonector 6 hours ago \| parent [-]
		It's still "TLS" as far as the application is concerned, which is why this could work, but yes, there are a few roadblocks, not the least of which is the absence of compelling HW. Another thing is that I/O is faster than compute nowadays, so making it faster may not be helpful :joy: