On Mon, 21 Jul 2025 at 01:11, Eric Rescorla <e...@rtfm.com> wrote: > On Sun, Jul 20, 2025 at 3:51 PM Thomas Fossati <thomas.foss...@linaro.org> > wrote: >> On Mon, 21 Jul 2025 at 00:12, Eric Rescorla <e...@rtfm.com> wrote: >> > On Sun, Jul 20, 2025 at 1:45 AM Mark Novak <mr.mark.no...@gmail.com> 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.
Point taken. We started sketching something along those lines in the intra-handshake document, but forgot to transplant it here. Clearly articulating the requirements for application developers, auditors, and RP/verifier owners will require some work. >> 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. Cool, thanks for confirming. >> 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. Yes, that's what I meant. Sorry for the conufsion. >> Does this match your expectations of what should happen? > > Other than the last point above, yes. Awesome. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
