Re: [Rats] New RATS Architecture document

[Giridhar Mandyam <[e-mail]>]

I have read through the latest version of the document.  At this time I do not think this document is ready to be the RAts architecture specirfication, and would object to its adoption as a Working Group draft.  I do believe the group needs an architecture document, however.  So if the editors can address my primary concern - a) below -  I would be happy to withdraw my objection.

-Giri Mandyam

a) I have asked the editors twice on the mailing lists for a justification as to why this is a standards track draft and not an informative one.  I have not received an answer, so I assume that there is no reason.  Note that comparable documents such as the TEEP architecture document and SUIT architecture document are informative.

b)  "... this document provides normative guidance how to use, create or adopt network protocols that facilitate RATS".  So in the context of EAT, does this mean that guidance provided in this document supersedes the EAT, CWT, and JWT specifications?

b)  "... trustworthiness claims are accompanied by a proof of veracity.  Typically, this proof is a cryptographic expression such as a digital signature or a message digest".  This is a misleading statement, as it could be interpreted to cover self-signing (see [3] for example), and I don't believe self-signing conveys any indication of trustworthiness.

c) As per h) of my previous review [4], I still cannot figure out how the concept of delegated attestation (e.g. Sec. 5.4 of [5]) would fit into this architecture.  For an informational document, it may not be strictly necessary to specify an architecture that can support delegated attestation since an informational document would likely not be expected to cover all scenarios.  Since this is being proposed as a normative specification however, we should ensure that it does not disallow what could be common remote attestation deployments.

For instance, as per the diagram in Figure 1, all evidence must be conveyed directly to the verifier and the verifier in turn produces "attestation results" to the RP.  But "attestation results" are the "output from the appraisal of Evidence, Known-Good-Values and Endorsements".  I take this to mean that attestation results cannot be evidence themselves.  However, the delegated attestation model in [5] allows for the appraiser (approximately equivalent to the RP as per the RATS architecture doc) to compose "separate layered or orthogonal attestations, involving different proxies, in order to make a judgment".

As per Sec. 4.4 RATS Principals, the multiplicity property may allow for multiple verifiers to take on the role of attestation proxies.  But multiplicity explicitly calls out that the instances of the principals take on the "same RATS roles".  If there are multiple proxies, then it seems that they would be assessing different subsets of evidence and therefore would be occupying different roles.  

d) RATS roles:  composition:  "RATS Principals possessing different RATS Roles can be combined in to a singleton ...".  I can understand some aspects of this property, e.g. combining the RP and Verifier.  But why would an attester and/or asserter be combined with a verifier and RP?  Do you know of an example? 

f) {Sorry to jump back}  Sec. 3.1.  "A Computing Environment with the capability of remote attestation ... is separate from other Attested Computing Environments (about which attestation evidence is created ...".  I could not tell if this definition allowed for solutions such as Android SafetyNet [6], where the rich execution environment (REE) is producing evidence about itself.  Is the intention of the RATS Architecture spec that such self-attestations not be considered valid for remote attestation?

g) Sec. 3.2.  "The RATS architecture anticipates recursive trustworthiness properties and the need for termination".   What is being terminated in this context?

h) Sec. 3.2.  nit.  "For example, design reviews, manufacturing process audits and physical security." This is not a complete sentence.

i)  Sec. 3.3.  "RATS architecture defines attestation Roles ..., the messages they exchange, ...".  Don't specifications such as EAT already define messaging in part?  If so, what would the RATS architecture be defining in addition?  

[1] https://datatracker.ietf.org/doc/draft-ietf-teep-architecture/. 
[2] https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/. 
[3]  https://www.w3.org/TR/webauthn/#self-attestation. 
[4] https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU. 
[5] J. Guttman et al.  “”Attestation:  Evidence and Trust”.  MITRE Technical Report MTR080072.  March 2008.  https://www.mitre.org/sites/default/files/pdf/07_0186.pdf. 
[6] https://www.w3.org/TR/webauthn/#android-safetynet-attestation. 


-----Original Message-----
From: RATS <[e-mail]> On Behalf Of Giridhar Mandyam
Sent: Tuesday, September 10, 2019 9:29 AM
To: [e-mail]
Subject: Re: [Rats] New RATS Architecture document

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Henk and other editors of the architecture doc,

I appreciate the effort put into this latest revision, and I will review it with a fresh eye. 

I do have one overarching question:  why is this document listed as 'Standards Track' (as opposed to 'Informational')?  I had expressed my concerns about this in an earlier review of the doc:  https://mailarchive.ietf.org/arch/msg/rats/9iIrnD9YixKCuwOGKtvGZIzd_bU. 

Since the editors' team is composed of experienced IETF'ers, I assume that there are solid reasons for doing so.  If you all have stated them before, I hope you do not mind me requesting that you lay out your reasons again because I seemed to have missed it.

-Giri

-----Original Message-----
From: RATS <[e-mail]> On Behalf Of Henk Birkholz
Sent: Tuesday, September 10, 2019 6:13 AM
To: [e-mail]
Subject: [Rats] New RATS Architecture document

-------------------------------------------------------------------------
CAUTION: This email originated from outside of the organization.
-------------------------------------------------------------------------

Hi all,

we created a fully revised architecture document that maps and represents the state of the current discussion and the material presented at the last IETF meeting.

The current Editor's version can be found here:

> https://ietf-rats.github.io/draft-birkholz-rats-architecture/draft-bir
> kholz-rats-architecture.html

We will submit a new version the day after the RATS virtual interim.

TL;DR
Below you can find a list of essential changes & a list of action items still to be addressed.


This version of the RATS Architecture document:

* does not define or uses the terms "root(s) of trust" (RoT) or "Trust Anchor" (TA) at the moment. (Note: It is a fact that the Asserter Role _is_ a TA for the Verifier Role and that an Attester Role _could_ rely on RoTs. But - this content will not go into the main body of this document),

* does define RATS Roles, Messages, and Principals formerly known as "Actors" (borrowing heavily from ABLP),

* provides an even more "base" interaction model diagram for the RATS Roles than presented in the last IETF meeting slide deck:

> https://datatracker.ietf.org/meeting/105/materials/slides-105-rats-ses
> sb-rats-architecture-interaction-model-challange-response-yang-module-
> information-module-00.pdf

* introduces a framework for "level of confidence" in the trustworthiness of an Attester and the endorsement of the protection characteristics of its "Attesting Computing Context", allowing for other entities to use this framework and fill it with, e.g., openly defined levels of confidence metrics,

* is not based on the primitive of "trust" but the concept of "trustworthiness" as illustrated by the RATS charter,

* simplifies the definitions of Attester and Verifier that seemed to have caused some unfortunate confusion following the proposal of Giri and starting with commonly-accepted definitions and then justify why they may need to be modified,

* differentiates between the Attesting Computing Environment and the Attested Computing Environment better, which both are components of an Attester,

* uses the "Claim" concept as a building block to compose Evidence, Known-Good-Values and Endorsements. Conversely, the "Assertion" concept is dropped in this proposal (as initially suggested by Laurence, IIRC?). 
(Note: this was done to simplify the discussion about the information model. Please also note: Due to the {J|C}WT definition of "Claim", a key/value pair is implied, which is already a data model decision and not mandated by an information model), and

* analogously, now uses the term Known-Good-Values instead of Attestation Assertions.


For future versions the authors intent:

* to elaborate on the use of RATS Principals, including more exemplary 
diagrams of RATS Role composition and interaction between RATS 
Principals based on the use case document (and by that address a unified 
mapping to TEEP, RIV, and models that use EAT),

* to shift some of the focus on technical-trust as proposed by Thomas. 
(the Endorsements provided by an Asserter are a first step into that 
direction),

* still not to define the roots of trust terms nor invent new words for 
them :) But - start to reference them on a minimal level and define a 
base set of primitives they can provide in order to describe what they 
actually are and can do in the context of RATS as proposed by Ira, Simon 
and Thomas,

* to introduce and define a concise scope for layered attestation, 
addressing, e.g., the staging of Computing Environments and the 
(un-)availability of an Attesting Computing Environment at certain 
points of time, or, another example given, addressing the 
differentiation of an attested boot sequence of an Attester and an 
Attester running TEEs or rich systems for years,

* to address the change of Roles of a Principal over time as proposed by 
Ian,

* to move the remaining architectural sections in the EAT draft into the 
RATS Architecture draft, and

* to shift some of the focus on the out-of-band trust establishment in 
order to illustrate a coherent RATS ecosystem (e.g. the provisioning of 
key material is not include in the "base diagram" anymore for now - this 
will be more elaborated on in future section of the architecture).


Viele Grüße,

Henk






_______________________________________________
RATS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rats
_______________________________________________
RATS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/rats