Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

[Giridhar Mandyam <[e-mail]>]

I also make an observation that some of the persons who are claiming confusion about whether security level is attestation evidence, attestation results or some form of self-declaration seem to be quite comfortable with comparable (maybe greater) ambiguity with TPM's.

For instance in https://www.ietf.org/archive/id/draft-ietf-rats-tpm-based-network-device-attest-14.html#name-notes-on-pcr-allocations:


  1.  "PCR[0] typically represents a consistent view of rarely-changed Host Platform boot components, allowing Attestation policies to be defined using the less changeable components of the transitive trust chain. "

How is a "rarely-changed" boot component identified?  Is this the "result" of a rules engine within the attester?



  1.  "PCR[4] is intended to represent the software that manages the transition between the platform's Pre-Operating System start and the state of a system with the Operating System present. "



What if there are multiple OS's in the system?  Which entity determines what constitutes the specific operating system that corresponds to this PCR?  Isn't this an attestation result as opposed to just evidence, as this value cannot be in the quote without a preliminary determination (result) identifying which SW is responsible for the transition to the target OS?



  1.  The text goes on to state "Although the TCG PC Client document specifies the use of the first eight PCRs very carefully to ensure interoperability among multiple UEFI BIOS vendors, *it should be noted that embedded software vendors may have considerably more flexibility*. Verifiers typically need to know which log entries are consequential and which are not (*possibly controlled by local policies*)"



So why is it OK for a RIV-compliant implementation (embedded software vendor) to assign arbitrary values to a PCR (which could conceivably span both evidence and results) with the expectation that a relying party/verifier to be able to apply the appropriate policy to interpret it, but it is unacceptable to expect a verifier to interpret sec level in the context of its own appraisal policy?

-Giri

From: Jeremy O'Donoghue <[e-mail]>
Sent: Thursday, June 2, 2022 12:29 PM
To: Laurence Lundblade <[e-mail]>; Henk Birkholz <[e-mail]>
Cc: Eric Voit (evoit) <[e-mail]>; Smith, Ned <[e-mail]>; Giridhar Mandyam <[e-mail]>; Eric Voit (evoit) <evoit=[e-mail]>; Nancy Cam-Winget (ncamwing) <[e-mail]>; [e-mail]
Subject: Re: [Rats] security-level claim (was Re: WGLC for https://datatracker.ietf.org/doc/html/draft-ietf-rats-eat)

I'm pretty happy with the latest text. It's a considerable improvement on what we had previously.

On 02/06/2022, 11:54, "RATS" <[e-mail]<mailto:[e-mail]>> wrote:


WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

On Jun 2, 2022, at 10:50 AM, Henk Birkholz <[e-mail]<mailto:[e-mail]>> wrote:

Hi Ned,

this also reflects my perception of group consensus.

Maybe be little careful about concluding what consensus is here?

There are an equal number of people expressing support of security level as there are questioning it.

Isn't consensus based on number of people, not on how long the list of questions is or how strong the view is?

LL