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

From: Daniel Migault <[email-masked]>
Date: Mon, 1 Nov 2021 16:59:33 -0400

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

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 2 Nov 2021 09:10:49 +0000

hi Daniel,

quick reply on just one point:

On Mon, Nov 1, 2021 at 8:59 PM Daniel Migault <[email-masked]>
wrote:section 10.

> the past and makes possible replay attacks.

Yes. That and a few other threats associated with manipulating the Epoch ID
timeline are discussed in Section 12.3 [1]

Let us know if something is missing.

Cheers, thanks!

[1]
https://datatracker.ietf.org/doc/html/draft-ietf-rats-architecture-12#section-12.3

---

From: Daniel Migault <[email-masked]>
Date: Tue, 2 Nov 2021 08:28:39 -0400

Hi Thomas,

Thanks! That is exactly what came to my mind while reading section 10 - but
did not make the link while browsing section 12.3. Thanks!

A non technical comment: It is correct section 12 points to section 10, -
but going through section 12 I did not pay sufficient attention to the
content of section 10. I have the impression the reference could be the
other way around - at least for me ;-) - that is section 10 pointing to
section 12.3.

Yours,
Daniel

On Tue, Nov 2, 2021 at 5:11 AM Thomas Fossati <[email-masked]> wrote:

> Yes. That and a few other threats associated with manipulating the Epoch
> ID timeline are discussed in Section 12.3 [1]
>

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Nov 2021 05:46:57 -0400

> in Figure 1. ## Two Types of Environments of an Attester

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

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

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

    > 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
    > the Attesting Environment.

    > Am I correct when I consider the system + keys as the root of trust ?

Yes.

    > 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

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.

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

    > claim_d = [claims_a, claims_b]. In both cases they represent the set of

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

    > by the hash(s). Myabe that worth clarifying how the set is represented.

No, that's not correct.

    > stored into the hardware. This, in my view, makes the states provided by

I can't really parse what you mean.

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

    > instead replaced by something around Upon starting an attestation, the

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

    > 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 = signed(claims)

    > information is valid - I am basically thinking of it as a TTL.

That's true.

    > Using Epoch

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 <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 3 Nov 2021 20:42:57 +0000

I looked for use of the term 'untrusted claims' in reference to Fig. 2 in rev 12 but couldn't find it.

If the conclusion after reading the section is that Evidence is 'untrusted' it might be more correct to regard Evidence as 'unverified' or 'un-appraised' Claims? 

I don't think there is meaning behind terms like 'attested evidence' as it is the same as just 'Evidence'. However, 'attested claims' could be considered synonymous with Evidence I suppose.

On 11/3/21, 2:47 AM, "RATS on behalf of Michael Richardson" <[email-masked] on behalf of [email-masked]> wrote:

    Yes.

    No, that's not correct.

    That's true.

    Yes that's correct.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Nov 2021 17:34:06 -0400

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

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

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

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

ok

>     > by the hash(s). Myabe that worth clarifying how the set is
ok

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

> In HTML it shows up in italics.

sure I was wondering if that were intentional.

> evaluate Evidence, and separated the void into the Trusted and the

;-)

> It could also indirect through session security, e.g.: TLS
Does authentic means authenticated then ? If not what is the difference ?

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

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

--

-- 
Daniel Migault
Ericsson

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Nov 2021 17:50:57 -0400

Thanks for the response,

I did not find untrusted claims in the text. What I wanted to raise is that
trusting the Attesting Environment may not be sufficient to trust the
claims and that the trust is conditional to the ability of the Attesting
Environment to get non tampered claims. If these are part of the same
hardware that is easier to understand. If Target Environment and Attesting
Environment are different pieces of hardware we also need to trust the
Target E and the communication between Target E and Attesting E. I assumed
Target E and and Attesting E were different pieces, but maybe I was wrong
and this is not the common use case.

I agree that attested claim can be seen as evidence. Actually the text they
are not signed and my questions started as what a signed claim could be. So
I tend to say the confusion is on me.

I think some of my questions came from the fact that I started reading
thinking of evidence as a signed hash of all claims.

Yours,
Daniel

On Wed, Nov 3, 2021 at 4:43 PM Smith, Ned <[email-masked]> wrote:

> If the conclusion after reading the section is that Evidence is
> 'untrusted' it might be more correct to regard Evidence as 'unverified' or
> 'un-appraised' Claims?
>
> I don't think there is meaning behind terms like 'attested evidence' as it
> is the same as just 'Evidence'. However, 'attested claims' could be
> considered synonymous with Evidence I suppose.
>
> On 11/3/21, 2:47 AM, "RATS on behalf of Michael Richardson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>

-- 
Daniel Migault
Ericsson

---

From: Michael Richardson <[email-masked]>
Date: Wed, 03 Nov 2021 18:04:53 -0400

Daniel Migault <[email-masked]> wrote:
    > Environment and Attesting Environment are different pieces of
    > hardware.

yes, that's somewhat reasonable for some TPM environments.

    > I

    > Attesting Environment from the Target Environment are not tampered.

yes, we can't defend against that.
If you have such a situation, then you need another Attesting Environment.
The Composite scenario is an example of that.
A real life scenario is a router chassis and a series of line cards.
Another real life scenario is a PC enclosure and smart-NICs and/or GPUs.

    > If we

There are real life attacks against the I2C that is used to talk to the TPM.
They can be mitigated if the I2C communication is encrypted to the TPMs
public key, but this requires that the system "bios" have a secure place to
put the TPM's public key.   This is possible some platforms that have some
secure space inside the CPU.

    > I do not think the figure needs to be changed and become more complex. I

Good.
How can we change the text to include your concern?

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

    > put assertion in the Target Environment.

some change needed?

    >> > have the impression cascading carries the notion of recurrence where

    > sure I was wondering if that were intentional.

Yes, intentional.

. o O ( then the elder ghods caused a post-quantum event... )

    > Does authentic means authenticated then ? If not what is the difference ?

Yes.
Evidence that has had a signature check would be authenticated.
Evidnece that was passed over a secure channel would not be have a signature
check, but would be trusted (due the channel) to be authentic.

    > hashes I wanted to represent a set. Not sure it is not only me.

I think that some of the underlying historic implementation infects the discussion.

---

From: Daniel Migault <[email-masked]>
Date: Wed, 3 Nov 2021 18:09:28 -0400

On Wed, Nov 3, 2021 at 6:04 PM Michael Richardson <[email-masked]>
wrote:

>     >> Any hash (ECDSA w/SHA256 for instance) involved in signing the
> Evidence,
>     >> is a
>     >> > If my understanding is correct, I would maybe clarify "contains".
> I
>     >> also
>     >> 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
Exactly. will check if I can propose something to improve the text by the
end of the week, but I am not too worried. The text is already in a good
shape and the document is easy to read.

-- 
Daniel Migault
Ericsson