Re: [Rats] RATS Digest, Vol 17, Issue 4

[Henk Birkholz <[e-mail]>]

Hi Ian,

as you 2nd Hannes comment & we also successfully confused Jürgen with 
it, I think we have to address this structure issue soon.

Please find preliminary proposals and comments in-line:

On 02.10.19 11:52, Oliver, Ian (Nokia - FI/Espoo) wrote:
> HI,
> 
> I'm in agreement with Hannes regarding the structuring of the document 
> and how the division between the concepts and terminology is made.
> 
> The terminology needs to be properly grouped together with the diagram 
> being almost the first thing presented such that a pictorial overview of 
> the relationships and terms can be ascertained by the reader. It appears 
> that some terms are also being introduced and defined in the concepts 
> section which I feel should be "less" formal.

If we would define the architectural constituents (and that term 
itself... I know) in the Terminology section that would pull a lot of 
content out of section 4. Let's assume that leaves enough intact text 
for now.

We would retain the "in-a-nutshell" section and reintroduce Creation, 
Conveyance, and Appraisal of Evidence there.

That should be enough to understand Figure 1 that complements that 
section, too.

Then - all terms and architectural constituents (which of course are 
named and therefore are terms...) go into section 2.

Does that sound sensible to you?

> 
> Section 3:  Does the RATS architecture provide a framework for 
> anticipating trustworthyness changes? I'm not 100% clear what is meant 
> by this line.

Yes - in general. But currently, the text is weak on elaborating on 
that. State transition will become its own section, I think.

> 
> Section 3.2: I wasn't sure if this is a definition of trustworthyness or 
> a statement about how the architecture established trustworthyness in a 
> system I'd rewrite this as below if the latter is the case:
> 
> "The trustworhyness of the remote attestation environment is  also (or 
> should also) be taken into consideration and the RATS architecture 
> addresses this"

Will add trustworthiness to the terminology section :)

Also, section 3.2 is too concise, I think. Being actually trustworthy 
and then the trustworthiness of RATS "capabilities" (e.g. the creation 
of evidence) are subtly different things. For both the following 
statement is true: "Ultimately, a portion of a computing environment’s 
trustworthiness is established via non-automated means. "

> 
> Are we also addressing the how aspect of this?

Yes - created Evidence is very often (but not exclusively) about the 
trustworthiness of an Attester. Created Evidence must always be 
trustworthy, though (coming back to the subtle differences hinted at above).

> 
> Do we also need to address roots and chains of trust/trustworthyness?

I think so. Not everybody thinks so :) The current compromise that has 
the best consensus is to refrain requiring roots of trusts in the body 
of the document, but elaborating about these core components in an 
appendix. Maybe it is warranted to address them in a section in the 
body, but for now we are composing a corresponding appendix.

> 
> 
> 
> Figure 1 & RATS Roles
> 
> If I take existing remote attestation systems then it appears to me that 
> the role of Attester is extremely broad taking into consideration quite 
> a large amount of RA implementation and also, to give a concrete 
> example, a large amount of the functioning of TPM 2.0, particularly the 
> Quoting, PCR and Sigining mechanisms to my understanding of this.  If 
> this is the point then I'm quite fine with that.

Yes, it is rather broad. But that is okay because we want to be 
inclusive wrt existing solutions and to be able to create a unified 
vocabulary/terminology for semantic interoperability between solutions.

Also, we are in the process of adding more complex compositions than the 
very simplified Figure 1. Most prominently the compositions presented by 
Dave.

> 
> (Sorry to use the TPM+RA example, but it is widespread and we do have a 
> working system that I'd like to be more compliant with this specification)
> 
> t.
> 
> Ian
> 
> 

Viele Grüße,

Henk

> 
> 
> -- 
> 
> Dr. Ian Oliver
> 
> Cybersecurity Research
> 
> Distinguished Member of Technical Staff
> 
> Nokia Bell Labs
> 
> [phone]
> 
> ------------------------------------------------------------------------
> *From:* RATS <[e-mail]> on behalf of [e-mail] 
> <[e-mail]>
> *Sent:* 02 October 2019 12:11
> *To:* [e-mail] <[e-mail]>
> *Subject:* RATS Digest, Vol 17, Issue 4
> Send RATS mailing list submissions to
>          [e-mail]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/rats
> or, via email, send a message with subject or body 'help' to
>          [e-mail]
> 
> You can reach the person managing the list at
>          [e-mail]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of RATS digest..."
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>