Rendered at 06:45:39 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
psanford 7 minutes ago [-]
I wish the author provided some latency numbers for this. One issue with tpms is that they are slow relative to performing the same operation on a modern CPU.
duk3luk3 3 hours ago [-]
Sounds interesting; too bad all we get is text made up by an LLM rather than any of the author's insights.
abound 3 hours ago [-]
Yeah I was interested for the first few paragraphs, then all of a sudden I get hit with two "genuinely"s and a
> That’s the third property, and it’s the one that decides this.
and I gave up at that point.
bschaatsbergen 14 minutes ago [-]
[dead]
ram_rattle 2 hours ago [-]
Nothing new here, attested TLS was being discussed in IETF for quiet sometime right?
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.
ram_rattle 42 seconds ago [-]
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!
madduci 20 minutes ago [-]
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
ranger_danger 3 hours ago [-]
Let's hope this doesn't get picked up by the (corporate) masses... the last thing I want is my browser offering personal TLS certificates to every server I visit as some kind of identity verification or fingerprint/tracking.
It's bad enough that ssh does this by default with all your keys.
zx8080 19 minutes ago [-]
This is most probably where it's going in less than a year. The recent campaign "Safer with Google" in Chrome hints to this.
altairprime 1 hours ago [-]
Client TLS is rather unusable on the Internet by a typical random end user visiting a random public site, so that should at least keep the specific scenario you describe at bay.
ranger_danger 57 minutes ago [-]
Currently yes, but there's not much stopping Chrome etc. from adding a new feature that has a way of presenting a client certificate to a website in a backwards-compatible manner.
Of course the website itself would need to support that, but it's all possible in time.
altairprime 28 minutes ago [-]
Chrome would be more likely to implement a persistent and identifiable (to Google alone) tracking cookie replacement and ship it worldwide, which iirc they did — and then cancelled, of course. They seem to be focusing instead on improved tracking of Android users from the kernel up, rather than browsers from the headers down; GrapheneOS is, presumably, viewed as a serious threat to their advertising revenue.
> That’s the third property, and it’s the one that decides this.
and I gave up at that point.
https://datatracker.ietf.org/doc/draft-fossati-tls-attestati... https://www.youtube.com/watch?v=MF9AwkMJOlw
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.
Hat Tip!
It's bad enough that ssh does this by default with all your keys.
Of course the website itself would need to support that, but it's all possible in time.
https://privacysandbox.google.com/blog/update-on-plans-for-p...