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

[Henk Birkholz <[e-mail]>]

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
>