Hi Ekr, On Fri, 18 Jul 2025 at 22:27, Eric Rescorla <[email protected]> wrote: > [...] > This brings us to the question of the binding to TLS. As a technical > matter, what this mechanism does is bind the operating environment on > the peer to the key used to authenticate the peer, but that leaves the > person trying to enforce higher-level properties with very little > guidance. What properties am I supposed to look at in the code to know > if the server operator can in this instance look at individual > responses? Because those properties are being provided by TLS (as > opposed to, say, encrypting over the top to the TEE), then it's > the responsibility of this document to provide some guidance (at minimum).
I believe the properties you are referring to above are out of the scope of aTLS. Instead, it’s RATS territory, specifically that kind of logic would be encoded in the "appraisal policy for evidence" and "appraisal policy for attestation results" (see section 4.2 of RFC9334 [1]). [1] https://www.ietf.org/rfc/rfc9334.html#section-4.2. Such a policy should check that: 1. The workload that implements your DAP-like logic has the expected measurement(s) (and therefore can be linked to an audited, possibly open-source codebase); 2. The platform that is executing your workload can provide an isolated execution environment for your workload (e.g., it’s a confidential computing platform), and ensure that the state of the platform (in terms of measured boot and run-time, configuration and state flags) is as expected; 3. The TLS authentication key is within the TEE boundary and, as such, it’s protected from exfiltration/manipulation. This last property is expressed, at least partly, via the EA binder, so I guess it belongs in aTLS. cheers, t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
