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

[Michael Richardson <[e-mail]>]

Daniel Migault <[e-mail]> wrote:
    > """
    > See Section 8 for further discussion of the conceptual messages shown
    > in Figure 1. ## Two Types of Environments of an Attester
    > """

Bizarre. A newline missing.
It seems to be fixed in the github copy already.

    > 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.

There are proposals to make this diagram more complex.
The editors don't want to do that because the diagram is already pretty
subtle.

I don't understand your statement,
  "are attested untrusted claims"

I don't understand the word "untrusted" here.
I think that it's pretty critical if we've confused you right here.

    > section 3.1

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

(that's section 3.2 in my copy.  Maybe the above editorial issue screwed up
the section number.)

This section is about _Layered Attestation Environments_

    > 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.

I don't understand your comment here.
Assert isn't used that much in the text.  It is used in the definition of
"Claim", and in the passport example, and then not again.
We sign evidence in the Attesting Environment in order to communicate the
value securely.  That can be EAT, TPM/Charra, UCCS+TLS, ...

    > 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 ?

Yes.

    > 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.

Figure 2 is a blow up of the interaction on the lower-left of Figure 1.

    > 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.

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

Claims are in general, not signed/integrity-protected.
Evidence is protected in some way when they are communicated.
It's also more than one key/value.

    > """
    > 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.

Extending a single PCR in a TPM results in a single Claim.
The Claims are not fed into the TPM.
Any hash (ECDSA w/SHA256 for instance) involved in signing the Evidence, is a
property of the signing algorithm, and not part of the Claim.

    > 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.

Yes, that's possible, but I think you are mixing implementation into architecture.

    > 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.

No, that's not correct.

    > 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.

I can't really parse what you mean.

    > section 8.4

    > _Strength of Function_ this is a markdown notation I suspect.

Yes, and in text form, that's how we represent italics, just like in email.
In HTML it shows up in italics.

    > 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....

In the beginning ("by default"), the universe was without form, and all Attesters were
untrusted.  Then, on the first day, God created the Verifier, and used it to
evaluate Evidence, and separated the void into the Trusted and the Untrusted.

    > It is a bit unclear to me what authentic means

It means, for instance that the signature has checked out.
But, not every system uses signatures directly.
It could also indirect through session security, e.g.: TLS

    > 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.

It seems that our attempt to be abstract has caused confusion.

    > Here I am reading Evidence as a set of Claims.

which is the definition of it :-)

    > 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.

Evidence = signed(claims)

    > 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.

That's true.

    > 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.

Yes that's correct.
Within an epoch we can not tell relative freshness of evidence.
The network could re-order things for instance.
But, evidence is signed, and it's usually idempotent.
Replaying the evidence by an attacker would be indistinguishable from a
network that duplicated/retransmitted packets.

{ps: I didn't open any issues on your review yet, but I'd like to}

--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide