Having PFS increases security for your end users. (Minus your storing of the session keys, of course; if whatever you need the session keys for doesn't require you to store them forever, then it still seems like a benefit.) Being able to use standard, well-audited libraries instead of a proprietary piece of "enterprise" code is a benefit.
> Aside from adding a ton of latency and extra performance overhead
The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware.
> you now have a new operational endpoint that you have to trust
No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.)
If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.
> Having PFS increases security for your end users.
The context of ETS/eTLS is that you yourself are the end user.
> The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware.
Uh-huh. I like that you believe that, but with a lot of HFT systems, even the latency of going from the NIC to the CPU is too much. Adding a hop in between that decodes and then reencodes, the the inherent buffering involved, is way, way too much latency.
> No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.)
>
> If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.
Yeah... see, that's the part you aren't getting. The old model was also not terminating through a proxy with TLS 1.2. That actually doesn't address the needs of the trusted system.
Having PFS increases security for your end users. (Minus your storing of the session keys, of course; if whatever you need the session keys for doesn't require you to store them forever, then it still seems like a benefit.) Being able to use standard, well-audited libraries instead of a proprietary piece of "enterprise" code is a benefit.
> Aside from adding a ton of latency and extra performance overhead
The performance of TLS on today's hardware is negligible; CPUs have instructions to accelerate it in hardware.
> you now have a new operational endpoint that you have to trust
No: In the prior TLS 1.2 design, the decryption key was on both the node MitM'ing the traffic, and the actual end nodes dealing with the traffic. The proposed TLS 1.3 alternative does not change that. (Nor does it improve it.)
If your TLS 1.2 was that you terminated at the node doing the MitM'ing, then do the same thing in TLS 1.3.