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. ________________________________ From: Eric Rescorla <e...@rtfm.com> Sent: Sunday, July 20, 2025 2:37 AM To: Muhammad Usama Sardar <muhammad_usama.sar...@tu-dresden.de> Cc: attested-...@ietf.org <attested-...@ietf.org>; r...@ietf.org <r...@ietf.org>; tls@ietf.org <tls@ietf.org>; Thomas Fossati <thomas.foss...@linaro.org> Subject: [Attested-tls] Re: [TLS] Review of draft-fossati-tls-exported-attestation-02.txt On Sat, Jul 19, 2025 at 5:11 PM Muhammad Usama Sardar <muhammad_usama.sar...@tu-dresden.de<mailto:muhammad_usama.sar...@tu-dresden.de>> wrote: On 19.07.25 21:21, Eric Rescorla wrote: On Sat, Jul 19, 2025 at 4:50 AM Thomas Fossati <thomas.foss...@linaro.org<mailto:thomas.foss...@linaro.org>> wrote: 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. A clarification question: did you mean * the draft should describe such guarantees in the security considerations section? * the draft should describe mechanisms which provide such a guarantee? 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? The bottom line here is: what do I as a relying party need to know in order for the attestation to actually provide meaningful practical security guarantees. If the former, sure, we can add this. If the latter, I don't think so. The problem is that we want to focus on protocol design and not eat the lunch of RATS :) No, I don't think so. The basic design concept of many (if not most) attestation systems is that the RP is forming a cryptographically secured channel to the system being attested to. In this case, that channel is being provided by TLS, and that means that the implications of the attestation for the security provided by TLS to said system are necessarily in scope. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
