I have seen some implementation of TLS using TPM 2.0 like the tpm2-tss-engine engine which can be used to protect the server private key associated with the certificate and sign with it inside the TPM. The same thing can be done with the client if client optional client authentication is enabled.
My question is whether the TPM would have the ability to protect the entire TLS 1.3 handshake. It will required to perform the ECDH key exchange with the TPM and keep the computed shared secrets in the TPM, then the HKDF should also be performed inside the TPM to protect all the derived secrets and keys. The TPM doesn’t support AEAD mode of operation but GCM for example could be implemented using ECB mode : the counter is incremented outside the TPM but each time it is encrypted in the TPM with ECB. The XOR with the plaintext and the computation of the authentication tag are also done outside. This way the symmetric keys never leave the TPM.
An interest of such an implementation would be to prevent an attacker to have access to the resumption master secret of a client even though this client is compromised. Thus the attacker would not be able to steal simultaneously the resumption master secret and the session ticket to later resume a session and spoof client identity if client authentication has been used in the handshake (the session ticket would then contain information about the client identity to avoid having to resend the certificate)
Does the TPM have the necessary functions to carry out this scenario and to protect all the secrets without revealing any outside ?