On Mon, 21 Jul 2025 at 00:12, Eric Rescorla <[email protected]> wrote: > On Sun, Jul 20, 2025 at 1:45 AM Mark Novak <[email protected]> wrote: >> >> Regarding this statement: >> >> I'm not sure I understand the distinction you are drawing here. >> Is "the keys stay in the TEE and aren't accessible to parts of the >> application other than those that are being attested to" a guarantee >> or a mechanism? >> >> On one level your observation is correct: the key must remain in the TEE and >> be safe from exfiltration. It is also 100% correct that the mere presence of >> a TEE does not guarantee that the key cannot (or would not deliberately) be >> exfiltrated from the TEE. >> However, what comes to the rescue in this case is a critical property of >> TEEs: they cannot lie about the code they are running. If the evidence >> provided by the TEE (inside the CPU-signed "quote") matches the reference >> value that is deemed correct by the Verifier, that's the only and best >> guarantee of the code being implemented correctly you can get. Of course if >> the reference values treat buggy code as correct, then all bets are off, but >> that's unavoidable. > > > The point I am trying to make is that whoever is examining the code needs > to know that this is a property they are looking for, along with some other > properties, and it is the job of this spec to tell them that.
This specification must define certain security properties that the execution environment may reasonably provide, e.g. the non-exportability of key material, the localisation of the TLS endpoint within the isolated environment, and the inability to act as an oracle, among others. These properties must then be translated by the appraisal policy on the RP side into concrete checks against the evidence supplied by the attester. The TLS protocol is not concerned with how this is realised, as it depends on the architecture of the hardware/software execution environment and the specific manner in which the TCB security metrics are exposed via evidence. I previously referred to this as "RATS territory". If the RP is satisfied that the evidence presented by the peer meets one or more of these properties, the negotiation with the peer will succeed and the attested secure channel will be established. Otherwise, the RP can either revert to normal TLS or shut the channel down. Does this match your expectations of what should happen? If so, I believe we are in full agreement, if not, please let me know what I am missing. cheers, t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
