On Mon, 21 Jul 2025 at 01:34, Watson Ladd <[email protected]> wrote: > On Sun, Jul 20, 2025, 3:52 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. > > > This has some nonobvious implications for structuring of the software > environment of the enclave.
True > For one thing the TLS stack can't be part > of the user-provided application and has to have some standalone > evidence applied. This may not always be possible, as it depends on the granularity of the measurements, which in turn tend to be constrained by the platform model and the application packaging arrangements. > These might be "RATS territory" but I think there's > a bunch of interplay with how the requirements feed back to TLS > implementations this WG is better suited to explore, just out of > familiarity. The problem has two complementary sides. Surely a graet deal of the required expertise is in TLS, but RATS can also offer a ton of theoretical knowledge and practical experience. cheers, t _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
