On Sat, Jul 19, 2025 at 4:50 AM Thomas Fossati <[email protected]> wrote:
> 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. > I don't agree. The relevant properties are TLS specific. > > 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. > As I said, it's nowhere near sufficient for the TLS authentication key to be in the TEE. For instance, there has to be a guarantee that the system not exfiltrate the traffic keys. -Ekr > > cheers, t >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
