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. -Ekr > ------------------------------ > *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> 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> > 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
