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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 1 Nov 2018 08:21:57 -0500

Hi all,

On Fri, Oct 26, 2018 at 07:54:52PM +0000, Roman Danyliw wrote:
> 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:

Dropping off some slightly scattered thoughts on the RC3 charter text
before I get on a plane ... sorry that they are not more well-formed.

I think we need to establish early on in the text (and use uniformly)
"systems and entities" as being the hardware of interest, and "roots of
trust or trust anchors" as the (crypto) mechanism to which attestation
claims will chain in order to be trustable.  This will help avoid ambiguous
parsings of later text as "(systems) and (entities that ...)"

I think I agree with Roman that the enumerated points in the "High Level
Goals" section could be dropped (which is good, since I also had trouble
parsing them unambiguously).

In the "high level goals":

The use of "trust*" words is a bit confusing, especially as to what is
already done and what the WG would need to do.  Maybe reordering "remote
entities" and "trust relationships" would help?  (Something like "A goal
of the RATS WG is to allow interaction with remote entities in a way that
can bootstrap a trusted relationship with the remote peer, leveraging
existing roots of trust or trust anchors available to the peer.", perhaps?)

There is probably a giant minefield about the precise meanings of "trust",
"trusted", "trustworthy", "trustable", etc. that we don't want to spend too
much time on pre-chartering.  That said, it would still help to keep in
mind while writing that not everyone has to trust the same people or
things, and so "trustworthy"/"trusted" are going to be relative to some
specific observer/party.  I will try to refrain from putting my thoughts on
"trust" into this thread; perhaps they will be appropriate in a later
thread.

I also don't know how the "correspondingly" follows in this section, and it
seems like the full-device attestation will be using one trust relationship
to bootstrap another (from the root to the communication peer).

[begin potentially obsolete comments]
In:
    1. Standardized and interoperable mechanisms to establish a sufficient
    level of confidence that data originates from trustworthy systems designed
    to support a specific set of operations/functionalities.

Are the mechanisms designed to support [things], or the trustworthy
systems?

In:
    2. Standardized and interoperable mechanisms building on (1.) to allow relying
    parties to know the attestation provenance and characteristics with respect
    to systems from which it may request services, consume information or to
    which a relying party may provide information.

I am not sure I can parse it correctly.  Does the RP need (attestation
provenance) and ([something else]), or (attestation (provenance and
characteristics)) with respect to [something]?
The best parse I can come up with is that the [something] ends up being
"with respect to systems", and the final list being descriptions of
attributes of the particular systems in question.  But "with respect to
systems" doesn't seem to add any value, leaving me confused.
[end potentially obsolete comments]

In the Program of Work:

When I see "establishing trust relationships" my first thought is some form
of initial contact when I go from a vacuum to "I will trust this entity [in
scope X]".  What we're doing here (IIUC) is more of a trusted introduction,
in that I already trust something and am leveraging that existing trust to
get a relationship with a new device/entity.  So, looking back at what I
just wrote, maybe I'm just uncertain about the verb "establishing", since
the thing we are getting does feel like a "trust relationship".  Perhaps
that suggests using "bootstrapping" or "forming", or adding a qualifier
"via trusted introduction".

(2) talks about "required use cases", but (1) only provides "sample
use-cases".  How will the required use cases be determined?

I'm also apparently missing a step between the modeling languages and
specifying syntax for claims -- I don't know whether the bridge between
them necessarily needs to be in the charter, but I'm not really seeing how
YANG at least comes into play for the described work.

I wonder if (4) has more detail than we need in a charter -- do we have to
say "reference values" and "measured file execution" to convey the intended
work and scope?

For (5), I doubt that the service graph depends on CWT vs JWT; the
verification procedures probably don't differ much either, once you have
parsed the things.  So maybe this could be refactored to just say "specify
procedures ... or appraisal of evidence.  [CWT] and [JWT] formats will be
considered for this work."

Some wording nits as well:

"establish trust in the trustworthiness of devices and services" is strange
wording

"claims or specific evidence about" could be "about one or more of the
following" to avoid an awkward dangling ", or".

"in encapsulated in" is redundant

-Ben