Re: [Rats] use case document updates on Roots of Trust

[Ira McDonald <[e-mail]>]

Hi,

Chiming in here.

The TCG is neither the originator of the term "Root of Trust", nor a
particularly good source for RoT definitions.

One might look at this US NIST project on Roots of Trust:

https://csrc.nist.gov/Projects/Hardware-Roots-of-Trust/publications

And especially this SP800-164 document:

https://csrc.nist.gov/publications/detail/sp/800-164/draft

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto: [e-mail]
PO Box 221  Grand Marais, MI 49839  906-494-2434



On Mon, Sep 9, 2019 at 6:49 PM Henk Birkholz <
[e-mail]> wrote:

> Hi all,
>
> wrt the topic of "roots of trust", on the list a very visible concern
> was highlighted: "the definition [of RoT] defines what they are -not-
> and not what it actually -are-". And I am inclined to agree with that.
>
> My initial and unpolished proposal is this:
>
> "If" we use the spectrum of meanings what "roots of trust" are in RATS,
> we probably have to do two things:
>
> 1.) We maybe should highlight that "Roots of Trust" are a demarcation
> line. There are system components or system components characteristics
> (aka "Claims" that are composed into "Evidence" about "Trustworthiness")
> that an Attester cannot create Evidence about only by itself. It is the
> "rock bottom" that an Attester cannot attest to (because, quoting:
> "their misbehavior cannot be detected"). While that being very true, it
> seems not to be enough of a reason to just exclude them conceptually.
>
> Hence, the only established procedure to "deal" with these roots of
> trust is a third's party endorsement. The consumer of attestation
> results is at its own liberty to put trust into these third party's
> endorsements - or not.
>
> It is an optional Claim Set, typically provided in the form of
> Endorsement Certificates (but there surely are other ways). And these
> methods might simply not be available to an Attester. And if that i that
> case that MUST not be a blocker, especially wrt to the RATS architecture.
>
> I.e. in RATS these Claims about RoT (Endorsements) should be purely
> optional. The architecture should allow to include them. But by any
> means, there should not be prescriptive or a normative MUSTs to provide
> them.
>
> If an Attester is able to provide or refer to such an endorsements of a
> system components capabilities, it should be able to do so. If an
> Attester is not able to provide such third party endorsements, that
> should not be a blocker to conducts RATS. The benefit of having the
> option to provide them is to fuel a framework about "levels of
> confidence" that most likely is out of scope of IETF definitions, but
> would enable other entities to fill that gap in.
>
> 2.) I am proposing that the RATS WG puts some effort in defining what
> "roots of trust" actually do (and not only what they cannot do). That
> would help to create an understanding what they actually mean - a lot.
> And - I think that is important - that might not have to be part of the
> architecture document. Maybe it is an Appendix of it, maybe it is an
> informational draft that complements the architecture document, or this
> content goes alongside with solutions drafts. We don't know yet, I think.
>
> TL;DR
>
> Roots of Trust are relevant. But their upcoming definition and use
> should not stop us from progressing essential corner stone drafts, today.
>
> My understanding is that some use cases really require them, and other
> use cases don't. Neither am I inclined to include them in the
> architecture draft and over-complicate elegant solutions, such as EAT,
> nor am I inclined to exclude them and thereby inhibit established
> solution, such as RIV.
>
> There is some middle ground here, I think. My proposal is to neither
> disregard the system components an Attester is not able to create
> Evidence for by itself, nor to mandate that an Attester can only create
> believable Evidence, if RoT are available. Both options should be
> enabled by the RATS architecture, I think.
>
> Viele Grüße,
>
> Henk
>
>
> On 09.09.19 22:56, Laurence Lundblade wrote:
> > Appreciate you wading into this with something written and concrete.
> >
> > As a thought experiment consider adding this to our RATS definition:
> >
> >     A root of trust may also be a simple unsecured user mode
> >     application, like an Android, Windows or Linux application that
> >     trust has been placed in by a particular attestation system. It is
> >     provisioned with a signing key or such and other capabilities so as
> >     to be able to produce attestation evidence (e.g. signed tokens).
> >       The application may or may not be signed or authenticated.
> >
> >     In a sense, the usual definition of root of trust applies in that it
> >     is something that is unconditionally trusted. In another sense, this
> >     is at odds with the usual conception as it is not anchored in HW or
> >     to any kind of system or boot SW.
> >
> > I assuming this addition is too much at odds with the convention usage
> > and there is no support for RATS adopting this definition. This is one
> > of the main reasons I am asking we not use the term normatively.
> >
> > LL
> >
> >
> >> On Sep 8, 2019, at 6:23 AM, Michael Richardson <[e-mail]
> >> <mailto:[e-mail]>> wrote:
> >>
> >>
> >> We seem to have regular email disputes on terms like Roots of Trust.
> >> I continue to have difficulty with the term. Particularly in the plural
> >> "Roots" form.
> >> As I process edits to the use case document, I got a bunch of text:
> >>
> >>   The TCG Glossary also offers a general definition for Root of Trust “A
> >>   component that performs one or more security-specific functions, such
> as
> >>   measurement, storage, reporting, verification, and/or update. It is
> >> trusted
> >>   always to behave in the expected manner, because its misbehavior
> >> cannot be
> >>   detected (such as by measurement) under normal operation. “
> >>
> >> {I personally find it very difficult to understand the words as other
> >> than an
> >> alias for Trust Anchor, yet it clearly is something else.  It's hard
> >> to make
> >> my neurons pull up a different meaning.  This is probably something that
> >> every RATS document should say clearly upon first using the term, in
> >> order to
> >> ease the impedence mis-match with IETF readers as we get reviews}
> >>
> >> I have included not just Ned Smith's comments about the term Roots of
> >> Trust,
> >> but his survey of the various origins of the term.  I'm sure that this
> >> belongs somewhere else.
> >>
> >> That diff is here:
> >>
> https://ietf.org/rfcdiff?url1=draft-richardson-rats-usecases-04&url2=https://ietf-rats-wg.github.io/ietf-rats-usecases/draft-richardson-rats-usecases.txt
> >>
> >> and commit is:
> >>
> https://github.com/ietf-rats-wg/ietf-rats-usecases/commit/7386e8c0df11ece66e3c95f85d141a639d440e12
> >>
> >>
> >> --
> >> Michael Richardson <[e-mail]
> >> <mailto:[e-mail]>>, Sandelman Software Works
> >> -= IPv6 IoT consulting =-
> >>
> >>
> >>
> >> _______________________________________________
> >> RATS mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/rats
> >
> >
> > _______________________________________________
> > RATS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rats
> >
>
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>