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

[Daniel Migault <[e-mail]>]

On Wed, Nov 3, 2021 at 5:47 AM Michael Richardson <[e-mail]>
wrote:

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

Thanks for the response. Let me rephrase myself.  Suppose that Target
Environment and Attesting Environment are different pieces of hardware. I
am saying this mostly as it is unclear to me if TPM is assumed to be part
of the CPU or as another piece of hardware.
What I was trying to say is that the verifier trusts the Attesting
Environment  and will trust in the Evidence.
However, there is also an implicit trust the claims retrieved by the
Attesting Environment from the Target Environment are not tampered.  If we
do not have that trust, the Attesting Environment will only be able to
attest claims that cannot be trusted.
Things can be simplified when the Target Environment and Attesting
Environment are part of the same hardware as there is a need to trust the
hardware. If the TPM is a different chip, it needs to be extended with the
BIOS and we need to trust this is the BIOS actually stored in the ROM.

I do not think the figure needs to be changed and become more complex. I
think it looks great.




>     > 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.
>
> My question was what means self-assert in the following sentence:

"""

In layered attestation, a root of trust is the initial Attesting
   Environment.  Claims can be collected from or about each layer.  The
   corresponding Claims can be structured in a nested fashion that
   reflects the nesting of the Attester's layers.  Normally, Claims are
   not self-asserted, rather a previous layer acts as the Attesting
   Environment for the next layer.  Claims about a root of trust
   typically are asserted by an Endorser.

"""

To me, as I understand the figure Claims are provided by the Target
Environment to the Attesting Environment. In my view the Attesting
Environment is responsible to add some trust to the Claim. Re-reading the
text, I have the impression this is what is being said.
I think what upset me was the use of self-asserted while the document never
put assertion in the Target 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.
>
> ok, so that comment was related to Claims that were self-asserted, in
which case they looked more like evidence. But I see to much focus on my
part on the self-asserted and I think the text is fine.


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

ok

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

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

I was trying to say that there is a need to ensure the claims are not
tampered. This is easier when Claims are transported over the same
hardware, but otherwise some mechanisms needs to be put in place ( = it is
more difficult).


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

sure I was wondering if that were intentional.

>
>     > 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
>
>
Does authentic means authenticated then ? If not what is the difference ?


>     > 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)
>
>
ok. I think the text is fine and that I was influenced by the hash of
hashes I wanted to represent a set. Not sure it is not only me.


>     > 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}
>
>
 If any issues are open these should be less than minor.

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

-- 
Daniel Migault
Ericsson