On Sun, Jul 20, 2025 at 3:51 PM Thomas Fossati <[email protected]> wrote:
> 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. > Yes. The point of this comment in my review is that I do not believe that the specification does this. > 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". > Yes, I agree. 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. > I'm not sure what "revert to normal TLS" would mean in the exported attestation setting: you've already established the TLS connection and are now sending this stuff over some application layer protocol. So isn't "revert to normal TLS" just "decide if you're willing to continue without an acceptable attestation. Does this match your expectations of what should happen? > Other than the last point above, yes. -Ekr 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]
