[Rats] draft-ietf-rats-architecture-12

[Daniel Migault <[e-mail]>]

Hi,

I could not see the draft-ietf-rats-architecture in the dt and was
wondering what is its current status. I am providing a review of the
document and hope the document can progress. The document is in a nice
shape.

I suppose the comments are only clarifying my understanding.

Yours,
Daniel


I suppose there is an editorial nits there:

"""
See Section 8 for further discussion of the conceptual messages shown
   in Figure 1. ## Two Types of Environments of an Attester
"""

>From Figure 2.

The trust associated with the Evidence is related to the trust of the
Target Environment as well as the communication of the Claims from the
Target Environment to the Attestation Environment. I think some
clarification/explanation may be added. My current reading is that
Evidence are attested untrusted claims which is not so useful.

section 3.1

"""
 Normally, Claims are  not self-asserted,
"""

seems to me a bit unclear, more especially, when a claim contains a value
of a register, I see the register as part of the Target Environment and the
register provides its value. I tend to see the register as self asserting
its value. Assert in the text seems to be related to the trust associated
with the value of the claim. If so, that assertion (or trust) results both
in the trust of the Attesting Environment (system + attesting keys) as well
as the system that enables the communication of the Claims to
the Attesting Environment. Am I correct when I consider the system + keys
as the root of trust ? But back the beginning of my comment I think I do
not understand what self asserted means and what the problem might be.
Maybe also I am mis-interpreting asserting as I do not understand it with
something stronger than a statement.
https://www.merriam-webster.com/dictionary/assert

Claims about a root of trust typically are asserted by an Endorser.

So Figure 1 shows the Endorser interacting with the Verifier. Figure 2
shows the interaction within the Attester and shows Claims being exchanged
between the Target Environment and the Attesting Environment while
Attesting Environment and Verifier exchange Evidences.  I am wondering if
that Claims should be replaced by Evidence or if the intention is to say
that Evidence is carrying/generated Claims trusted by a root of trust -
which in this case is associated to the Target Environment and not the
Attesting Environment.

"""
 The
   final Evidence thus contains two sets of Claims: one set about the
   bootloader as measured and signed by the BIOS, plus a set of Claims
   about the kernel as measured and signed by the bootloader.
"""

I understand that the set of claims are combined together with for example
a hash function. In other words, Evidence is not (necessarily) a list of
claims that can easily be extracted from the Evidence.
If my understanding is correct, I would maybe clarify "contains". I also
have the impression cascading carries the notion of recurrence where one
level includes all levels below - but that is my own perception. Overall I
have the impression that [claims_a, claims_b] can have multiple
representations including claim_c = hash(  [claims_a, claims_b] ) or
claim_d = [claims_a, claims_b]. In both cases they represent the set of
claim_a and claim_b.

4.2

"""
Evidence:  A set of Claims generated by an Attester to be appraised
      by a Verifier.  Evidence may include configuration data,
      measurements, telemetry, or inferences.
"""

This is mostly what is just mentioned above. To me a set of claims is s = (
claim1, claim2, ..., claimn) and I have the possibility to take s[0], but I
have the impression that the set here is more abstract and is represented
by the hash(s). Myabe that worth clarifying how the set is represented.

section 7.4

  1.  The key material used to authenticate and integrity protect the
       conveyance channel is trusted by the Verifier to speak for the
       Attesting Environment(s) that collected Claims about the Target
       Environment(s).

The text does not mention the trust in the Claims. I have the impression
that it also conveys some trust in the claims.
In the case of the BIOS, we do put similar trust into the hardware to load
properly the BIOS stored into the ROM as we trust the attestation keys
stored into the hardware. This, in my view, makes the states provided by
the TPM trusted.

section 8.4

_Strength of Function_ this is a markdown notation I suspect.

By default, the Relying Party does not believe the Attester to be
   compliant.  Upon receipt of an authentic Attestation Result

I do not see any reason to perform attestation if the Attester is known to
be compliant. I am wondering if "by default" is appropriated or should be
instead replaced by something around Upon starting an attestation, the
Relying....

It is a bit unclear to me what authentic means, so I am checking if it
should not be replaced by trusted or simply being removed. Unless I am
missing it, I noticed authentic is widely being used across documents so it
might be worth defining it in the architecture document. At least I am
happy to be pointed to its definition.


Section 9:

9.  Claims Encoding Formats

The section is mostly focused on Evidence and Attestation Results, not so
much on Claims. That said, the discussion is a generic discussion over
which format to use and this can be extended to Claims as well, though in
some cases Claims may have proprietary formats.

What is unclear to me in the section is the relation between Claims and
Evidence, and I think that is related to previous comments. Here I am
reading Evidence as a set of Claims. So I am wondering if we expect
Evidence format to be a list of Claims in which Claims can be either built
from the Attesting Environment or provided by a Attesting Target. Typically
I do see measurements as new Claims generated by the Attesting Environment.
I agree that in both cases these are inside the Attester.

section 10.

All timekeeping methods seem to me to have an implicit period when the
information is valid - I am basically thinking of it as a TTL. Using Epoch
ID, I have the impression that a new ID indicates a new time slot, so I am
wondering if blocking the time distributor does not keep the device into
the past and makes possible replay attacks.

-- 
Daniel Migault
Ericsson