Subject: Re: [Rats] Architecture document review

From: Henk Birkholz <[email-masked]>
Date: Thu, 17 Oct 2019 16:02:14 +0200

Hello Kathleen,

please find comments on your input inline.

On 24.08.19 13:50, Kathleen Moriarty wrote:
> Greetings!
> 
> Thank you very much to the authors of the RATS architecture document.
>  It is clearly evolving and the current discussion on list should
> help to shape it further.  Acknowledging that it is a early draft,
> the flow could be improved and consistency in writing style could be
> as well.
> 
> General comments: By referring to this as the RATS architecture, are
> we including EAT in that?  I'm just questioning this use of terms
> early as sometimes the WG name just goes away and is not the same as
> resulting protocols specified.  What does RATS architecture mean in
> this sense?  Is it all things the WG develops or just RATS work?

EAT is the most prominent serialization (with corresponding data- &
information-model) and is included by the Message concept.

The use of "RATS*" is already reduced and will be reduced down to a
level where it is actually only a word substitution for "remote
attestation procedures" in the context of a sentence.

The "Remote Attestation Procedures Architecture" is a document that
enables interoperable remote attestation procedures. If the definitions
in this document are used they can be mapped to existing and emerging
remote attestation procedures, e.g. Android KeyStore Attestation, Fast
Identity Online, Remote Integrity Verification, Time-based
Uni-Directional Attestation, the TEEP architecture workfows, or CHARRA.

The intent is to create a "Profiles" for each of the examples and also
enable future solutions to do the same thing in IETF documents. By doing
so the semantics of messages conveyed in separate solutions can also be
mapped and a remote attestation service can support multiple solutions
in a seamless way as long as the message types, the roles of the
services involved and the information elements (e.g. defined by
information models in EAT ort Basic YANG RA, etc.) can be mapped.

Every document created can be mapped to (a subset) of the architecture
and therefore can be placed in the architectural model. Entities working
on solutions therefore can so what is already there and fill the gaps to
create a functioning interoperable solution that uses unified
terminology, so there is no confusion what each part the solution solves
or is intended to do to assess the trustworthiness of a communication
partner.

> 
> A diagram of how the components fit together would go a long way
> towards having the document feel more like an architecture document
> than a terminology document.  It would also help with removing the
> text on "RATS Roles" being a "building block".  That text seems to
> just be from one author based on writing style, so I think it can
> easily be removed. The diagram setting forth the relationships
> between architectural components would be really helpful for the
> reader early in the document to see how each of the defined
> components fit.  This was likely already planned, but is worth
> mentioning.

The editor's version now starts with a concise glossary and the
terminology is defined in greater detail in corresponding section later
on. We are in the progress of pulling diagrams in that illustrate the
relationships between the introduced concepts (architectural constituents).

> 
> My comments are focused more on earlier sections and I tried not to 
> overlap with active discussions.  My intent is to help improve the 
> document and move it towards something the WG could adopt near term
> if updated.
> 
> Abstract:
> 
> First and second sentence: Remote ATtestation ProcedureS (RATS)
> architecture facilitates the attestation of device characteristics
> that, in general, are based on specific trustworthiness qualities
> intrinsic to a device or service. S/qualities/factors/ I don't think
> qualities is the right word.  Factors or something else leaves this a
> bit more open and to things that we may be able to nail down (or
> others defining levels, etc.)..

The whole paragraph was refactored and "intrinsic qualities" are gone
now. Semantically, they are replaced by "security aspects" or
"trustworthiness properties" when applicable.

> 
> On the general comment, should we look at terminology usage in cases
>  like this sentence: The RATS architecture maps corresponding 
> attestation functions and capabilities to specific RATS Roles. s/RATS
> Roles/Roles/

The use of the "RATS*" is reduced, but not entirely yet. Will fix.

> 
> I'd recommend cutting the following sentences out of the abstract as
>  they are a bit confusing since there's not enough of an explanation
> to understand what it means.  If it makes sense, these could go to
> the introduction and be clarified.
> 
> The RATS architecture maps corresponding attestation functions and
> capabilities to specific RATS Roles.  The goal is to enable an
> appropriate conveyance of evidence about device trustworthiness via
> network protocols.  RATS Roles provide the endpoint context for
> understanding the various interaction semantics of the attestation
> lifecycle.
> 
> And
> 
> Example usages include, but are not limited to: financial
> transactions, voting machines, critical safety systems, network
> equipment health, or trustworthy end-user device management./

Both sections are cut out.

> 
> Introduction:
> 
> The first sentence reads as if this will be an operational guidance 
> document..  Maybe add something about the architecture and how things
>  fit together?
> 
> In general, this document provides normative guidance how to use, 
> create or adopt network protocols that facilitate remote attestation 
> procedures.

Is replaced by: "In general, this document provide an composable
architectural model the enables to map separate existing and emeging
solution and identify or define their place in a RATS ecosystem.2

> 
> I suggest a re-write of the introduction to better explain the
> problem being solved.  This is meant to be an introduction to the
> problem space and later the architecture is described to help solve
> that problem.

Upper part of the Introduction is a complete rewrite.

> 
> Perhaps starting from a diagram would be helpful to establish a
> cohesive set of thoughts for the later described architecture that
> may help structure the document.  Once the WG agrees to this
> architecture, then update the structure and written prose?

On it.

> 
> The problem in this document is the architecture to support remote 
> attestation procedures - explain what that means, what problem is
> being solved.

Was the illutration good enough or is the readability still lacking?

If the text illustrated above is a good step forward, we will pull that in.

> 
> Section 1.1 - I think you can remove the word "Unfortunately" and
> still get the point across.  This is a crisper write up to help a
> reader get started and maybe should come before any other
> introduction text.

Fixed

> 
> Section 1.2 - This reads as if the architecture document is all about
>  setting terminology and it is really a terminology document
> undercover as an architecture document.  I'd strike all of this
> text.

That section is now removed.

> 
> Section 2 - Since no other goals are discussed, I suggest removing
> that part of the first sentence:
> 
> OLD: One of the goals of the RATS Architecture is to provide the
> building blocks - the roles defined by the RATS Architecture - to
> enable the composition of service-chains/hierarchies and work-flows
> that can create and appraise evidence about the trustworthiness of
> devices and services. NEW: The RATS Architecture provides the
> building blocks, including the roles that enable the composition of 
> service-chains/hierarchies and work-flows that can create and
> appraise evidence about the trustworthiness of devices and services.

The old passage was cut and the new proposed sentence added to the end 
of the Introduction

> 
> Question: Is the architecture really all about the roles? The
> emphasis on roles is important, but I think the wording puts too much
> on it and then takes away from the architecture structure and
> definition intended for this document.  I think this perception from
> my read goes away if you remove the suggested text and make the
> change to the first sentence in this section or just have this
> section start from the sentence:

A big chunk of it are the 4 roles. Profiles can use only a subset or 
define additional ones. The four base ones are the central points for 
mapping and interopability.

We moved the focus away from roles and extended it to: entities, roles, 
messages, and message properties.

> 
> The RATS Architecture is based on the use-cases defined in 
> [I-D.richardson-rats-usecases].
> 
> The bulleted list seems to be a mix of what's in the architecture and
>  requirements for the architecture.  That should be cleaned
> up/separated.

On it.

> 
> The bulleted list that follows removes this focus on roles.
> 
> First bullet: OLD: o  The building blocks to create remote
> attestation procedures applicable Actors, Roles, Duties, and
> Interactions, NEW: o  The building blocks to create remote
> attestation procedures including applicable Actors, Roles, Duties,
> and Interactions,

As highlighted above the new "building-blocks" are the architectural 
constituents.

> 
> Section 3.1: The notion that a "role" is a building block is
> confusing.  I'd recommend removing this terminology.  Wouldn't the
> attestation (claims and signature) be the building blocks?
> Everything else is needed to support that in the architecture to
> attain a trustworthiness level.

Fixed.

> 
> I have more thoughts on definitions, but will be brief for now.
> 
> Attester definition - Would like to see evidence defined first and
> you can remove "attester" that precedes evidence in the first
> sentence.

The new "Essential Terms" section hopefully addresses this in an 
appropriate way. Does it?

> 
> Authentication checker: Please reword, run on sentence that is
> difficult to read.  There are too many thoughts within the same
> sentence.

That one is so gone :)

> 
> Section 4.1.5 Suggested change If more than one RATS Role resides on
> the same RATS Actor, a network protocol might not be required. s/Role
> resides on the/ Role is performed by the/

That passage is gone.

> 
> Section 7 -
> 
> This gets difficult to read again.  The last few sections were much 
> better.  A lot of text in 7 can be deleted as it doesn't aid in 
> understanding the scope before the "In essence" paragraph.

The passages in question where cut to rebuild them via a structured WG 
process.

> 
> Somewhere in this section, there should be a discussion of the
> expected bounds of a protocol in that an attestation may be
> legitimate, but there may be compromised software that was
> undetected.  The responsibility for that software sits with the
> attester, which is a key attribute for attestation users.  Having the
> responsibility for the integrity and security of attested code sit
> with the originator or the attester is a key feature.

This is an open action item / issue.

> 
> 
> Thank you again for all of your work on this document to date, it's
> much appreciated! --
> 
> Best regards, Kathleen

Sorry for commenting on the changes to the document based in your input 
so late! Paralleling the work increased the pace at which the document 
is improving, significantly.

Viele Grüße,

Henk
> 
> _______________________________________________ RATS mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rats
>