Subject: [Rats] Architecture document review

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 24 Aug 2019 07:50:53 -0400

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?

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.

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.).

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/

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.

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.

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.

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?

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

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.

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.

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.

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:

   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.

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,

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.

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.

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

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/

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.

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.

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

Best regards,
Kathleen

---

From: "Smith, Ned" <[email-masked]>
Date: Mon, 26 Aug 2019 17:44:25 +0000

Regarding Kathleen’s question about scope of ‘RATS architecture’[1]. My view is RATS architecture is inclusive of EAT. The EAT draft contains information model elements, information model binding elements  - in the form of CWT and JWT tokens, and a little bit that is related to architecture, terminology and conveyance protocol. The EAT draft as an architecture seems less general than is needed to support the use cases and the other proposed drafts.

It seems there is good progress being made on the list and through reader feedback regarding ways to improve the architecture. I anticipate there will be a revision later this week that is an improvement over the current draft.

-Ned

On 8/24/19, 4:51 AM, "RATS on behalf of Kathleen Moriarty" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> 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:
[1]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?
[snip]

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 26 Aug 2019 14:14:33 -0400

On Mon, Aug 26, 2019 at 1:44 PM Smith, Ned <[email-masked]> wrote:

> Regarding Kathleen’s question about scope of ‘RATS architecture’[1]. My
> view is RATS architecture is inclusive of EAT. The EAT draft contains
> information model elements, information model binding elements  - in the
> form of CWT and JWT tokens, and a little bit that is related to
> architecture, terminology and conveyance protocol. The EAT draft as an
> architecture seems less general than is needed to support the use cases and
> the other proposed drafts.
>
>
>
> It seems there is good progress being made on the list and through reader
> feedback regarding ways to improve the architecture. I anticipate there
> will be a revision later this week that is an improvement over the current
> draft.
>

Thank you very much, Ned and the other authors.  Yes, the dialog has been
quite productive and I look forward to seeing the updated document.

Best regards,
Kathleen

> -Ned
>
>
>
> On 8/24/19, 4:51 AM, "RATS on behalf of Kathleen Moriarty" <
> [email-masked] on behalf of [email-masked]>
> wrote:
>
>
>
> Greetings!
>
>
>
> [1]By referring to this as the RATS architecture, are we including EAT in

-- 

Best regards,
Kathleen

---

From: Laurence Lundblade <[email-masked]>
Date: Mon, 26 Aug 2019 13:05:45 -0700

> On Aug 26, 2019, at 10:44 AM, Smith, Ned <[email-masked]> wrote:
> 

I generally agree with this assessment. It is my thought to take most architecture that remains in the EAT draft out of the EAT draft. It would be good to wait until architecture draft is more solid and complete before doing so.  The architecture and terminology that is in the EAT draft is there from when it was not part of RATS and not even inheriting from CWT and JWT.

I don’t really think the EAT draft has any conveyance protocol in it and that is a good thing. It is should be neutral and usable with any conveyance protocols.

LL