Comment by ram_rattle
7 hours ago
Nothing new here, attested TLS was being discussed in IETF for quiet sometime right?
https://datatracker.ietf.org/doc/draft-fossati-tls-attestati... https://www.youtube.com/watch?v=MF9AwkMJOlw
7 hours ago
Nothing new here, attested TLS was being discussed in IETF for quiet sometime right?
https://datatracker.ietf.org/doc/draft-fossati-tls-attestati... https://www.youtube.com/watch?v=MF9AwkMJOlw
That's right, I'm learning in public here. That draft is a different direction though, they change the handshake: new TLS extensions carry the evidence, and the far end appraises the platform during the connection.
What I'm doing changes nothing on the wire, the verifying side has no idea a TPM is involved. In RATS (https://www.rfc-editor.org/rfc/rfc9334.html) we prove a machine is sound by measuring it and appraising the evidence. But after attestation the usual thing is to hand the machine a short-lived identity saying it is attested, and when that machine then authenticates over mTLS to something like an HSM, the thing that gives that machine its identity is a private key in a file. That bothered me. What I want is to tie the key in the TPM to the evidence of the confidential VM at issuance time, and let that be the identity the machine carries afterwards. Working notes while implementing RFC 9334.
Never mind, I had no idea who you where, looked you up, please take a bow, apologies if the comment came out rude, more power to your work and agree learning in public and publishing more will what will make this idea better.
Hat Tip!
Attested TLS has had some rough patches lately which can be attributed to making big changes to a complex protocol.
It really better to separate the attestation, the check against policy and then the TLS stuff. Solve one problem at a time, sign that progress and move on.
Exactly, you could do this also with the Microsoft Cryptographic Provider long time ago, which is the basic Provider called by the go-tpm library, when running under Windows