bschaatsbergen

Joke's on them, I don't have the key either.

Thanks for sharing Ted!

What mjg59 says. The benchmarks are against a vTPM, that was what I had access to, and it's the environment I'm implementing the RATS side in.

Worth adding that not every outbound connection needs to go through the TPM (IMO). It's for the handful of services where the machine-identity actually matters, a secret store, or an HSM releasing key material onto an attested confidential VM, in my case.

Author here. There's a benchmark table further down the post, the numbers come from this repo if you want to run them yourself: https://github.com/bschaatsbergen/go-tpm-tls-bench

Author here. All of it is mine, the library (https://github.com/bschaatsbergen/go-tpm-tls) and the benchmarks (https://github.com/bschaatsbergen/go-tpm-tls-bench) and the working notes. English isn't my first language, so I edit a lot, and I can see how that comes out flat. I've been over it once more; hopefully it reads better now. Thanks for saying so rather than just closing the tab.

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.

Author here, thanks for posting this. Been going deeper on TPMs lately, working through machine identity after remote attestation, the point where you've proven a machine is genuine but still need it to prove which machine it is to something like a secret store. crypto/tls takes any crypto.Signer, so this library slots a TPM-resident ke in and signs the handshake without the key ever leaving the hardware; happy to answer anything on the library or the attestation side.

That's, indeed, a spec limitation, not something cek can solve. If you're interested in provenance tracking, you might want to look at Sigstore's cosign attestations or GUAC (Graph for Understanding Artifact Composition).

Skopeo and crane are both fantastic tools, but they address different problems at a different level. Skopeo and crane operate at the image registry level, handling pulling, pushing, synchronizing, etc. cek is focused on what's in the container itself, providing a programmatic way to explore a container’s (overlay) filesystem and layers with commands like ls, tree, and cat.

While they may look similar at first glance, Dive and Cek target different use cases. Dive is great at visualizing layer content and analyzing image efficiency, but requires the Docker daemon and can't extract file contents. Cek is daemonless (works with any container runtime or none at all) and focuses on providing a programmatic interface: `ls`, `tree`, `cat`, etc. for exploring a container's overlay filesystem and layers.

Good to know you enjoyed the read!

Both Marc Brooker (lead developer on the AWS Lambda team) giving the talks at Re:Invent as I mentioned in the footnotes, and the official documentation that's out there will provide you with a lot of information.

Great article @mlerner