Re: [Rats] Comments on draft-birkholz-rats-architecture-01

[Nicolae Paladi <[e-mail]>]

Hello,

Some comments on draft-birkholz-rats-architecture-01<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01>

3.1. RATS Roles


 Verifier:  The consumer of attestation evidence that has a root of
      trust for verification (RTV), implements conveyance protocols,
      appraises attestation evidence against reference values or
      policies, and makes verification results available to relying
      parties.

Root of trust for verification (RTV) is neither defined, nor introduced nor referenced anywhere in the document.


4.1.4 Relying party Duties

Evaluate assertions/evidence locally as far as possible

- The formulation  is inadequate and looks like a “wish” rather than a duty; rephrasing “as far as possible” can fix it;
- What is the difference between Evaluate vs Appraise for a Relying party? *Evaluate* becomes redundant after reading 4.1.5 RATS Interactions - paragraph “Attester/Relying Party”:

A Relying Party typically requires external help to either validate authentication information or to appraise evidence presented by an Attester.



4.1.5<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-4.1.5>.  RATS Interactions


Attester/Relying-Party:  A Relying Party typically requires external help to either validate authentication information or to appraise evidence presented by an Attester.  In most cases, a Relying Party requires a corresponding Verifier to process the assertions/evidence received.  In consequence, (a subset of) the information received by an Attester must be relayed securely to a Verifier.


- “Received by” seems to be incorrect here; while the Attester “consumes assertions about itself” (as per 3.1:Attester), it seems more reasonable that the authors meant “sent by”? Otherwise the sentence should bine rewritten to make it clearer.



5.1. Trust and Trustworthiness


If the root of trust involved is a root of trust for measurement (RTM), the producer of information takes on the role of a asserter. An asserter can also make use of a root of trust for integrity (RTI) in order to increase the level of assurance in the assertions produced.  If the root of trust involved is a root of trust for reporting (RTR), the producer of information takes on the role of an attester.

Unless the asserter role is not a “first class” RATS role, it makes sense to describe it   already in "3.1 RATS Roles”

5.2. Claims and Evidence


The RATS asserter role produces measurements about the system’s characteristics in the form of signed (sometimes un-signed) claim sets in order to convey information.

“Sometimes un-signed” introduces a great deal of uncertainty without further explanation. The difference between signed and unsigned claim sets will have implications on the trustworthiness of the system and needs to be explained in more depth.



   The RATS asserter role produces measurements about the system's
   characteristics in the form of signed (sometimes un-signed) claim
   sets in order to convey information.  A secret signing key is
   required for this procedure, which is typically stored in a shielded
   location that can be trusted, for example, via a root of trust for
   storage (RTS).

   The RATS attester role produces signed attestation evidence in order
   to convey information.  The secret key required for this procedure is
   stored in a shielded location that only allows access to that key, if
   a specific operational state of the system is met.  The trust with
   respect to this origination is based on a root of trust for
   reporting.

The two paragraphs are at least partly overlapping.


5.3. RATS Information Flows


There are six roles defined in the RATS architecture.

This seems to imply that “asserter” is a RATS role and should be defined in 3.1


iFigure 2 provides a simplified overview of the RATS Roles defined above

Only four roles are included in the figure. Was that intended?



7.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-7.1.1>.  How the RATS Architecture Addresses the Lying Endpoint Problem





 RATS imply the involvement of at least two players (roles) who seek
   to overcome the lying endpoint problem.  The Verifier wishes to
   consume application data supplied by a Computing Context.  But before
   application data is consumed, the Verifier obtains Attestation
   Evidence about the Computing Context to assess likelihood of poisoned
   data due to endpoint compromise or failure.  Remote Attestation
   argues that a systems's integrity characteristics should not be
   believed until rationale for believability is presented to the
   relying party seeking to interact with the system.

“Likelihood” implies a probabilistic approach to trustworthiness (e.g. 42% likelihood of poisoned data”). Is that really feasible? And if so, is it actually of any use? IMO trustworthiness is binary (“trustworthy or not trustworthy”), or binary and conditional/contextual (“trustworthy if used for certain actions”).




8.1.1<https://tools.ietf.org/html/draft-birkholz-rats-architecture-01#section-8.1.1>.  Characteristics of a Computing Context


Computing context characteristics provide the following: * An
      independent environment in regard to executing and running
      software, * An isolated control plane state (by potentially
      interacting with other Computing Contexts),

It remains unclear - an environment independent of what? Is a TPM equally independent as a container and as an SGX enclave or a standalone discrete device? Likewise for “isolated”.


Computing context characteristics do not necessarily include a
   network interface with associated network addresses (as required by
   the definition of an endpoint) - although it is very likely to have
   (access to) one.

It is not clear what definition of endpoint the authors refer to.



8.3. Core RATS Terminology



   $ Remote Attestation:  A procedure involving Attestation, Conveyance
      and Verification.



Is remote attestation _exclusively_ consist of Attestation, Conveyance and Verification, or does it _involve_ them among other actions?



 $ Attested (Asserted) Claim:  An Attestable Claim where the proof
      elements are populated.

   $ Evidence (Claims) Creation:  Instantiation of Attested Claims by a
      Claimant.

   $ Evidence (Claims) Collection:  Assembling of Attested Claims by an
      Attester for the purpose of Conveyance.

   $ Verified (Valid) Claim:  An Attested Claim where the proof elements
      have been verified by a Verifier according to a policy that
      identifies trusted Claimants and/or trusted Evidence values.


The terms in parenthesis (Asserted, Claims, Claims, Valid) seem to be redundant. It is not clear what is their purpose.


Misc. comments, throughout the document:

● AttestEr and AttestOr are used concurrently. I suggest to stick to “AttestEr”.


—
Nicolae Paladi,
RISE Research Institutes of Sweden



On 7 Jul 2019, at 17:17, Thomas Hardjono <[e-mail]<mailto:[e-mail]>> wrote:


Here are some comments on draft-birkholz-rats-architecture-01.

There are several typos in the text,  but I will focus on some of the more fundamental questions.


(a) Abstract:

the goal of the RATS Architecture is
to enable interoperable interaction between the RATS Roles. Hence,
the RATS Architecture is designed to enable interoperability via
well-defined semantics of the information model (attestation
assertions/claims),...

Is it true/correct that RATS will address the semantics of the information model (and not just the syntax).

The issue of trust semantics goes very deep into the architecture of the hardware and platform, so much so that  I don't think (correct me) it is practical to compare between two hardware manufacturer platforms (e.g. Intel based PC versus Qualcomm-based iPhones) .  The best that can be achieved (correct me) is that there is a paired-matching between the Computing-Context measured/reported by the device (Attester) and the Computing-Context information (manifest) issued by the Asserter (platform or device manufacturer) and accessible to the Verifier.  The Verifier must somehow know (detect) the differences in Computing-Contexts between two distinct platforms/devices.

Or did I misunderstand the usage of the term "semantics" in this document.


(b) Page 4

One of the goals of the RATS Architecture is to provide the building
blocks - the roles defined by the RATS Architecture - to enable the
composition of service-chains/hierarchies and work-flows that can
create and appraise evidence about the trustworthiness of devices and
services.

The notion of "service-chains" or assertion-chains needs to be defined clearly (maybe in the next draft).  In fact, service-chains is a topic that is barely discussed in this draft-01.


(c) Page 5 top:

Mandatory and optional trust relationships between its Roles, that
may assume a Root-of-Trust context,

This one is confusing I think, because perhaps of the word "optional".

One of the outcome of a successful RATs interoperability scenario is to enable the establishment of trust (based on the observance of RATS-defined remote attention procedures) between the Asserter and Verifier.


(d) Page 5 Section 3.1 on RATS Role.

Claimant:

I'm assuming we going with the word "Asserter" instead of Claimant.


(e) Page 6 second paragraph:

... supply chain entities (SCE)...

Supply chain entities need to be defined.  Does this mean supply chain of components that make-up a platform (e.g. OEMs), or does it mean something else.



(f) Page 6 third pa paragraph a:

Attester: The producer of attestation evidence that has a root of trust for reporting (RTR)

Why only the RTR?  I would have thought that the Attester (e.g. my device) must also have an RTM.


(g) Page 7, last paragraph:

In general, and RATS Duties are typically associated with a
RATS Role. The list presented in this document is exhaustive.

Did you mean "exhaustive" or "non-exhaustive"


(h) Page 8, Section 4.1.2:

Acquisition and storage of appraisal policies

The term "appraisal policies" needs to be defined.  Dos it mean "processing rules" ? (akin to the X509 cert policies which define the ways to process received certs).


Verification of Attester Identity (attestation provenance)

Is this a typo?  An "Attester Identity" is not the same as the provenance of attestations.


(i) Page 12 first paragraph:

In essence, the
attestation provenance of attestation evidence is the system that
intends to present its trustworthiness in a believable manner.

This sentence sounds circular, but I think I get the intent.

Should it read something like:  The provenance of the attestation-evidence of a given system originates from the system itself, and pertains to the trustworthiness of the system.  It must be presented in a believable manner by the system to external entities, namely the Verifiers and Relying Parties.


(j) Page 12 fourth paragraph:

If the root of trust involved is a root of trust for measurement
(RTM), the producer of information takes on the role of a asserter.


Is this a typo?  Should this instead read ".. the role of an *Attester" (because an Attester, not the Asserter, has the RTM and possibly RTR).


(k) Page 15 Section 7.1

The Lying Endpoint Problem text should be placed in the Use Cases document, not in the Architecture doc.

The entire reason we have RATS (and indeed the whole notion of Remote Attestations) is largely due to the The Lying Endpoint Problem.


(l)  Page 21 section 8.1:

This paragraph is a good explanation of remote attestations because it talks about "telemetry", which seems core to network devices.

Perhaps this paragraph could be moved up front towards the start of the document.


(m) Page 22 Section 8.4:

Claim: Structured Evidence asserted about a Computing Context. It
contains metadata that informs regarding the type, class,
representation and semantics of Evidence information. A Claim is
represented as a name-value pair consisting of a Claim Name and a
Claim Value

Firstly, I would avoid the use of the term "Claim" because it is already used in higher layer protocols and other organizations. The term "Assertion" is good enough for RATS.

Secondly, is the goal/deliverable for RATS to define these name-value pairs? (for both RTMs and RTRs).

The TCG uses the term "manifest" to indicate the list of expected compliments and measurements in the platform, produced by the Asserter (e.g. device manufacturer).


(n) Page 23 second-last paragraph:

Activity: A sequence of actions conducted by Computing Contexts
that compose a Remote Attestation procedure.

Should RATS care about the "activity" or actions of s given device or platform (that concludes in the generation of an attestation).  Isn't activities/actions internal to the device and the device-manufacturer.


(o) Other comments:

The diagrams from the RATS architecture presentation at IETF104 are excellent ("Evolution of RATS Architecture" and "RATS WG Scoping").  It would be good to have them represented somehow in ASCII.





-- thomas --




























_______________________________________________
RATS mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rats