On Sat, Jul 19, 2025 at 5:11 PM Muhammad Usama Sardar < [email protected]> wrote:
> On 19.07.25 21:21, Eric Rescorla wrote: > > On Sat, Jul 19, 2025 at 4:50 AM Thomas Fossati <[email protected]> > 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 -- [email protected] To unsubscribe send an email to [email protected]
