Yeah, not really sure that’s simpler or even addresses the same attack vector Google’s option does. First of all, this approach have the nice fact that now we

Yeah, not really sure that’s simpler or even addresses the same attack vector Google’s option does. First of all, this approach have the nice fact that now we need new TPMs capable of doing that, and even if people could update it, we will need to wait for everybody to update their TPMs. So lets wait another 10 to 15 years before we’re really sure. Second, the attack vector google’s approach is trying to protect against is assuming someone stole your cookies. Might as well assume that someone has gained root on your machine. Can you protect against that? Google’s approach does regardless of how “owned” your machine is, yours doesn’t. It’s not like you’re gonna hand off the TLS stream to the tpm to write a bit into it, then hand it back to the OS to continue. The tpm can’t write to a Linux tcp socket. whatever value the tpm is returning can be captured and replayed indefinitely or for the max length of the session. So you’re back where you started and you need to have a “keep alive” mechanism with the server about these sessions. Google’s approach is simpler. A private key you refresh your ownership of every X minutes. Even if I’m root on your machine. Whatever I steel from it has a short expiration time. It cuts down the unnecessary step of having the tpm hold the cookie too. Plus it doesn’t introduce any limitations on the cookie size