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

From: Daniel Migault <[email-masked]>
Date: Fri, 10 Dec 2021 09:08:26 -0500

Just to close the thread as the arch doc moves forward. I believe the
current version addresses all my concerns.
Yours,
Daniel

On Wed, Nov 3, 2021 at 6:09 PM Daniel Migault <[email-masked]> wrote:

>
>
> On Wed, Nov 3, 2021 at 6:04 PM Michael Richardson <[email-masked]>
> wrote:
>
>>
>> Daniel Migault <[email-masked]> 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 <[email-masked]>   . o O ( IPv6 IøT consulting
>> )
>>            Sandelman Software Works Inc, Ottawa and Worldwide
>>
>>
>>
>>
>>
>
> --
> Daniel Migault
> Ericsson
>

-- 
Daniel Migault
Ericsson