Subject: [Rats] Re: Security considerations of remote attestation (RFC9334)
From: lgl island-resort.com <[email-masked]>
To: Muhammad Usama Sardar <[email-masked]>
Cc: "Panwei (William)" <william.panwei=[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Jan 2025 22:16:11 +0000
List-Id: Remote ATtestation procedureS <rats.ietf.org>

On Jan 2, 2025, at 1:19 PM, Muhammad Usama Sardar <[email-masked]> wrote:

Hi Laurence,

On 02.01.25 18:34, lgl island-resort.com wrote:
I looked at Usama’s draft.

Thank you for checking it.
Seems like there two points to make:

1) The evidence needs to be authenticity and integrity protected *in* the attesting environment. Or conversely, the quality of the attestation is only as good as the security of the environment that its authenticity and integrity is established in.

2) It needs to use attestation-oriented key material (see my previous message).

Right.
It doesn’t matter so much whether CMS, COSE, TLS or other are used as long as they are used with these characteristics. We like COSE because it fits in to attesting environments nicely. We are cautious about TLS because it is typically not used this way.

That's part of the problem that I want to highlight. The statement in RFC9334 quoted in my draft makes "broad" claims without excluding TLS. It only says "A conveyance protocol that provides authentication and integrity protection" and TLS is one that indeed does provide both.

I think TLS is OK, but you have run it in a TEE or such. You shouldn't run it in the HLOS (the OS that runs user apps, graphics and such) if you want higher levels of security.

And the TLS must do client auth with key material that came from the device vendor or the attestation provider or such.

LL