On 20.07.25 03:37, Eric Rescorla wrote:
On Sat, Jul 19, 2025 at 5:11 PM Muhammad Usama Sardar <muhammad_usama.sar...@tu-dresden.de> wrote: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.
The former is stating those requirements (in the security considerations section) that the TEE must implement and the RP's Verifier need to check. The latter is describing mechanisms provided by TEEs to meet these requirements.
From a formal perspective, the former will partly come from the assumptions in the security properties. The latter is irrelevant to the formal proof.
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?
It is a guarantee.
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.
There are some baseline requirements that we must state which will be implemented in the appraisal policy checks depending on the peer's architecture. For example, for a given RP, the answer can vary from:
* knowing just an authenticated public key of the Verifier and checking the signatures and a single bit (yes/no) from the Verifier to * RP checking every minute detail itself, partly presented in [1].
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.
I think the word "implications" answers my clarification question. If yes, I am in total agreement with you.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.
Usama [1] https://ieeexplore.ieee.org/document/10373038
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
