Subject: [Rats] Feedback on the RC3 draft charter text

From: Roman Danyliw <[email-masked]>
Date: Fri, 26 Oct 2018 19:54:52 +0000

Hello!

I reviewed the v3 draft charter text at https://github.com/ietf-rats/charter/blob/RC3/ietf-rats-charter.md, and had the following feedback/recommendations/questions:

(1) Use consistent language for the "things" participating in the attestations.  Each section uses slightly different language -- "devices and services"/"communication partner"/"relying party" (in introduction); "devices, services and other third parties" (in high level goals); or "systems/entities", "system/remote party" (in Program of Work).

(2) In the introductory section, I wanted to read a bit more about the context -- establish why RATS is needed; notionally define what "trust" and "trustworthiness" means; what is the continuum of "communication partners" under consideration.

(3) Per this sentence in the introduction, "In the absence of such procedures, while domain-specific attestation mechanisms such as TCG TPM/TSS, FIDO Alliance attestation and Android Keystore attestation exist, there is no common way for a relying party to tell if data originates from a trustworthy device or not.":

** I recommend removing the "In the absence of such procedures" phrase.  It is redundant.

** I like that this sentence acknowledges the related work.  In this section, the list of related work is "TCG TPM/TSS, FIDO and Keystore".  In the High Level Goals section, another set of related work is listed, "Global Platform, TCG and FIDO".  Are these meant to be different.  Couldn't Global Platform also be listed in this sentence.

** Per the notion that the domain-specific attestation methods aren't adequate,  is the language "there no common way" the same as "there is no general purpose way"?  

(4) I struggled with the text in the "high level goals" section as the details of the WG goals are buried in the text.  I would recommend opening this section with a declarative statement of the form "The goal of the RATS working group is to specify the formats, protocols and procedures needed to create and verify trust relationships suitable for remote attestation."

The sentence "Correspondingly, the RATS WG will facilitate full device attestation ..." introduces new terminology for me that begs explanation (and wasn't references in the introduction).  

IMO the two bullets, under "The WG will define .." aren't necessary because the next section already abstractly defines the activities and there will eventually be a set of milestones that will be even more specific.

(5) Program of Work: Per, "The Working Group will develop standards supporting the creation of interoperable remote attestation procedures for systems and entities which incorporate roots of trust.":

I wasn't able to tell if the closing phrase "which incorporates roots of trust" was intended to scope the problem.  In the previous section which discussed High Level goals, RATS was going to work with both "roots of trust or trust anchors".  I'd recommend consistency in language.

(6) Program of Work.  Activity 1

I recommend simplification as follows:

- "Specify an architecture establishing a common terminology for remote attestation, identifying mechanisms which will be supported for establishing trust relationships between a system and a remote party, and enumerating sample use-cases for remote attestation."
+ "Specify a reference architecture that defines common terminology and samples use cases for remote attestation"

(7) Program of Work.  Activity 2

I recommend simplification as follows:

-"Specify interoperable cross-platform claims which provide information about systems and entities in support of the required use-cases, and extending the set of claims defined in RFC7519 and RFC8392. The specification will describe the syntax for each claim in at least the following formats:"
+"Extend the set of claims defined in RFC7519 and RFC8392 with additional ones applicable to the required remote attestation use cases."

The activity makes reference to "retaining interoperability with existing formats based on ASN.1".  What are those formats?  They should be stated explicitly.

(8) Program of Work.  Activity 4

As it relates to claims specification, I'm not sure how this would be different than Activity #2.

(9) Program of Work Activity 6

I recommend dropping this bullet.  This analysis should be an implicit activity but not a deliverable.

Roman

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 26 Oct 2018 23:29:48 +0200

Hi Roman,

thank you for the detailed input. A few first thoughts in-line (most of 
them most certainly not final).

Viele Grüße,

Henk

> (1) Use consistent language for the "things" participating in the attestations.  Each section uses slightly different language -- "devices and services"/"communication partner"/"relying party" (in…

Understood. There was a deliberate attempt to remove a terminology 
subsection (charter size/readability/complexity amongst others). The 
reasoning behind that: if you go down the path of defining terms, the 
"common terms" that are used a bit loosely right now have to be "nailed 
down". There are at least four side effects to that, I think:

1.) everybody gets a better understanding of what a terms mean
2.) the charter will increase in size
3.) more terms will have to be defined as there are now, because precise 
definition will lead to more precise specialization
4.) using the "correct" terms in the "correct" places might re-initiate 
the cycle of discussion we were attempting to break (I am neutral on this)

Having said that, I am still rather confident that we can agree on a set 
of terms here, but it will not be limited to the taxonomy that is 
implicitly defined via "devices and services"/"communication 
partner"/"relying party" and similar examples that were highlighted. The 
different flavors of roots of trust (which we do barely elaborate on) 
require a more fine grained definition of terms in any case. I am okay 
with this (as that was the initial approach), but I am not sure about 
the impact on current consensus in the scope that is this list.

> (2) In the introductory section, I wanted to read a bit more about the context -- establish why RATS is needed; notionally define what "trust" and "trustworthiness" means; what is the continuum of…

These terms are defined rather explicit or via minor derivation from 
RFC4949, maybe a reference might mitigate that?

> ** I recommend removing the "In the absence of such procedures" phrase.  It is redundant.

No objection

> ** I like that this sentence acknowledges the related work.  In this section, the list of related work is "TCG TPM/TSS, FIDO and Keystore".  In the High Level Goals section, another set of related…

Yes

> ** Per the notion that the domain-specific attestation methods aren't adequate,  is the language "there no common way" the same as "there is no general purpose way"?

If you would ask me, there is a significant difference between purpose 
(effectively  intended) and common (effectively realized) way. But that 
PoV is probably my very own specific one.

> (4) I struggled with the text in the "high level goals" section as the details of the WG goals are buried in the text.  I would recommend opening this section with a declarative statement of the fo…

This sounds like the statement of work. Does this imply we might not 
need a high level overview here (which intrinsically is redundant to the 
actual work by being a generalized overview)?

> IMO the two bullets, under "The WG will define .." aren't necessary because the next section already abstractly defines the activities and there will eventually be a set of milestones that will be…

Yes, there are new terms here. They are important to some stakeholders 
and probably not as important to others (which is true to every work 
item, I assume). I am not sure how to remidiate that without a dedicated 
terminology section, which we tried to avoid based on multiple 
recommendations. I'd really like to address this specific comment (not 
with proposals right now, I mean, but conceptually). Hence, this is one 
of the points, where more guidance wrt to intent and scope of your 
comment would really help, I think.

> I wasn't able to tell if the closing phrase "which incorporates roots of trust" was intended to scope the problem.  In the previous section which discussed High Level goals, RATS was going to work…

Personally, I would boil it down to RoT and go into the details of RoT 
and TA in draft text. I was the one, who introduced it. I am okay with 
removing TA again.

> + "Specify a reference architecture that defines common terminology and samples use cases for remote attestation"

Simpler, but allowing for more ambiguous scope, I think. Leaning a bit 
more to simplicity, I'd not object.

> +"Extend the set of claims defined in RFC7519 and RFC8392 with additional ones applicable to the required remote attestation use cases."

On one hand, this could imply that "required use-cases" might be a way 
to channel everything into the scope of work. On the other hand, it 
sounds way simpler, which is the +1 here.

> The activity makes reference to "retaining interoperability with existing formats based on ASN.1".  What are those formats?  They should be stated explicitly.

Do you mean DER/BER/PEM (which is simple) or the semantics they were 
burdened with in the last 25 years (which is hard)?

> As it relates to claims specification, I'm not sure how this would be different than Activity #2.

That is true. But I think that is also rather relevant to other 
stakeholders, who can most likely provide more detaila on this matter.

> I recommend dropping this bullet.  This analysis should be an implicit activity but not a deliverable.

Then it should not be dropped, but moved one section up, right? It most 
certainly does seem relevant due to endorsement on the list.

> Roman

Viele Grüße,

Henk

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

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 29 Oct 2018 14:18:10 +0000

Hi Henk!

Responses inline ...

> -----Original Message-----
> From: Henk Birkholz [mailto:[email-masked]]
> Sent: Friday, October 26, 2018 5:30 PM
> To: Roman Danyliw <[email-masked]>; [email-masked]
> Subject: Re: [Rats] Feedback on the RC3 draft charter text

[snip]
> > I reviewed the v3 draft charter text at https://github.com/ietf-
> rats/charter/blob/RC3/ietf-rats-charter.md, and had the following
> feedback/recommendations/questions:
> >
> > (1) Use consistent language for the "things" participating in the
> attestations.  Each section uses slightly different language -- "devices and
> services"/"communication partner"/"relying party" (in introduction);
> "devices, services and other third parties" (in high level goals); or
> "systems/entities", "system/remote party" (in Program of Work).
> 
> 4.) using the "correct" terms in the "correct" places might re-initiate the cycle
> of discussion we were attempting to break (I am neutral on this)
> 
> Having said that, I am still rather confident that we can agree on a set of
> terms here, but it will not be limited to the taxonomy that is implicitly defined
> via "devices and services"/"communication partner"/"relying party" and
> similar examples that were highlighted. The different flavors of roots of trust
> (which we do barely elaborate on) require a more fine grained definition of
> terms in any case. I am okay with this (as that was the initial approach), but I
> am not sure about the impact on current consensus in the scope that is this
> list.

I agreed that we don't want to invest substantial text defining a taxonomy.  The gist of my suggestion is for us not use multiple taxonomies in parallel in the text.  Readability would be greatly improved if terms discussed in the introduction would then be evident in the work areas (whereby connecting the stated problems/state of the practice with the proposed work).

> >
> > (2) In the introductory section, I wanted to read a bit more about the
> context -- establish why RATS is needed; notionally define what "trust" and
> "trustworthiness" means; what is the continuum of "communication
> partners" under consideration.
> 
> These terms are defined rather explicit or via minor derivation from RFC4949,
> maybe a reference might mitigate that?

Makes sense to me to make the reference.

[snip]

> > ** Per the notion that the domain-specific attestation methods aren't
> adequate,  is the language "there no common way" the same as "there is no
> general purpose way"?
> 
> (effectively  intended) and common (effectively realized) way. But that PoV
> is probably my very own specific one.

OK.  This was a semantic nit on my part.  I'm fine with the text as is since we're on the same page.

> > (4) I struggled with the text in the "high level goals" section as the details of
> the WG goals are buried in the text.  I would recommend opening this
> section with a declarative statement of the form "The goal of the RATS
> working group is to specify the formats, protocols and procedures needed to
> create and verify trust relationships suitable for remote attestation."
> 
> This sounds like the statement of work. Does this imply we might not need a
> high level overview here (which intrinsically is redundant to the actual work
> by being a generalized overview)?

I think it is helpful to introduce the work, but only if it the generalization adds content.  Somewhere in this charter text it would be helpful to have one or two sentences that summarize what the WG will do.  My editorial recommendation is to open the text with what the WG will do instead of restating the need.  I would recommend against collapsing the section with the program of work because it references key areas of coordination in-and-out of the IETF.  

[snip]

> > (5) Program of Work: Per, "The Working Group will develop standards
> supporting the creation of interoperable remote attestation procedures for
> systems and entities which incorporate roots of trust.":
> >
> > I wasn't able to tell if the closing phrase "which incorporates roots of trust"
> was intended to scope the problem.  In the previous section which discussed
> High Level goals, RATS was going to work with both "roots of trust or trust
> anchors".  I'd recommend consistency in language.
> 
> Personally, I would boil it down to RoT and go into the details of RoT and TA in
> draft text. I was the one, who introduced it. I am okay with removing TA
> again.

IMO, simplicity (and consistency) would help here.

[snip]

> > The activity makes reference to "retaining interoperability with existing
> formats based on ASN.1".  What are those formats?  They should be stated
> explicitly.
> 

I'm not sure, that's why I'm asking.  I read the sentence as there being a requirement for interoperability with unspecified ASN.1 formats.  Maybe examples would help here.

> That is true. But I think that is also rather relevant to other stakeholders, who
> can most likely provide more detaila on this matter.

OK.  To others on the list, can a bit more explanation be provided please?

> certainly does seem relevant due to endorsement on the list.

Sure.  I read all of the other program of work  items as items that would manifest as a document.  I'm leery of work items that won't be a formal draft.  Perhaps the next decomposition of work items to milestones would clear up that confusion.  It would also endorse the "phased approach" to delivery previously discussed.

Roman