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

[Daniel Migault <[e-mail]>]

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

>
> Daniel Migault <[e-mail]> wrote:
>     > Thanks for the response. Let me rephrase myself.  Suppose that Target
>     > Environment and Attesting Environment are different pieces of
>     > hardware.
>
> yes, that's somewhat reasonable for some TPM environments.
>
>     > 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.
>
> 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
>     > 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.
>
> 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
>     > think it looks great.
>
> Good.
> How can we change the text to include your concern?
>
>     >> My question was what means self-assert in the following sentence:
>
>     > """
>
>     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.
>
>     > """
>
>     > 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.
>
> some change needed?
>
>     >> > """
>     >> > 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
>
>     >> > 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.
>
> Yes, 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.
>     >>
>
>     > ;-)
>
> . o O ( then the elder ghods caused a post-quantum event... )
>
>     >>
>     >> > 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 ?
>
> 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.
>
>     >> 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.
>
> I think that some of the underlying historic implementation infects the
> discussion.
>
>
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.

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

-- 
Daniel Migault
Ericsson