[KMag]

> If they just store traffic and can decrypt it afterwards with the private key that they likely already protect with very high security, I think that's better than having to log traffic and all the session keys which need to be protected in the same manner as the private key...

The point of "perfect" forward security is that it's not possible to recover session keys using only the secret key and the (logged) handshake data.

One solution would be to modify the server's stack to use kerberos or some other low-overhead encrypted channel to send the session keys to the logging server so that the session keys can be logged along with the encrypted data. Another, less scalable, solution would be to have a border proxy set up the TLS 1.3 session keys and then set up a connection from the border proxy to the internal server using TLS 1.3 PSK such that the internal and external connections use the same session key. Both of these solutions would allow a border proxy to decrypt and filter traffic without the overhead of having the border proxy decrypt and re-encrypt the traffic. The border proxy could decrypt and process traffic, and if no problems are found, forward the still-encrypted data to the internal server.

Yes, with TLS 1.3 it will be a pain to set up logs that make customer data more vulnerable to theft. It will still be possible, and multiple vendors will gladly implement it for banks and sell to banks.