[Rats] RATS Architecture continued

[Kathleen Moriarty <[e-mail]>]

Greetings!

I got as far as I could with time constraints through the rest of the
document.  There are a few sections I'll likely go back over again as I was
short on time when reviewing them, but do hope this is helpful towards
improving the document.  This review is from the editors revision on github
that I started my review earlier int he week.

Section 4.2:
I find the following grouping a bit confusing:
"Places that Attesting Environments can exist include Trusted Execution
Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware."

This has an attesting environment as a processor, an element, and as
compiled code.  That doesn't seem right, especially when you refer to the
attesting environment as a "place".  Do you mean where BIOS is executed
perhaps?  I would expect a TEE and maybe other components where security
functions are offloaded, which is in some cases to a processor other than a
TEE like a GPU (I'm not making a recommendation to do that here, just
stating what is happening in ecosystems that exist).

The following text is a little confusing, in particular, the last sentence:
"An execution environment may not, by default, be capable of claims
collection for a given Target Environment. Attesting Environments are
designed specifically with claims collection in mind."

If the attesting environment is a place, TEEs and other processors were not
necessarily designed with claims in mind.  If you can help to explain an
attesting environment better, I can help to phrase it more clearly to
convey the intended set of points as I think there are several.

Section 4.3
Consider changing from:
"By definition, the Attester role takes on the duty to create Evidence."
To:
"By definition, the Attester role creates Evidence."

The following sentence is a run on and I think some additional information
will help provide clarity. I don't think it's the role that is composed of
nest environments.  Current:
"The fact that an Attester role is composed of environments that can be
nested or staged adds complexity to the architectural layout of how an
Attester can be composed and therefore has to conduct the Claims collection
in order to create believable attestation Evidence."
How about:
"An Attester may be one or more nested or staged environments, adding
complexity to the architectural structure.  The unifying component is the
root of trust and the nested, staged, or chained attestations produced.
The nested or chained structure should include claims, collected by the
attester to aid in the assurance or believability of the attestation
Evidence."

The following sentence should be broken into two:
"This example could be extended further by, say, making the kernel become
another Attesting Environment for an application as another Target
Environment, resulting in a third set of Claims in the Evidence pertaining
to that application."
Proposed:
"This example could be extended further by making the kernel become another
Attesting Environment for an application as another Target Environment.
This results in a third set of Claims in the Evidence pertaining to that
application."


How about changing the following sentence from:
"Among these routers, there is only one main router that connects to the
Verifier. "
To:
"A multi-chassis router, provides a management point and is the only one
that connects to the Verifier. "

For the following sentence, trying to remove the use of a word twice in a
row and convey the same intent.
Old:
"After collecting the Evidence of other Attesters, this inside Verifier
verifies them using Endorsements and Appraisal Policies (obtained the same
way as any other Verifier), to generate Attestation Results."
Proposed:
"After collecting the Evidence of other Attesters, this inside Verifier
uses Endorsements and Appraisal Policies (obtained the same way as any
other Verifier) in the verification process to generate Attestation
Results."

I may try another pass at section 4 to improve readability.

Section 5,
Consider breaking this into 2 sentences, from:
"This section includes some reference models, but this is not intended to
be a restrictive list, and other variations may exist."
To:
"This section includes some reference models. This is not intended to be a
restrictive list, and other variations may exist."

Section 5.1
Two result words together is not necessary.
Change from:
"The second way in which the process may fail is when the resulting Result
is examined by the Relying Party, and based upon the Appraisal Policy, the
result does not pass the policy. "
To:
"The second way in which the process may fail is when the Result is
examined by the Relying Party, and based upon the Appraisal Policy, the
result does not pass the policy. "

I suggest making the last paragraph the second paragraph.  It's easier to
read than the others and provides an introduction to the model before you
begin talking about how it might fail.

** I may come back to this section to provide wording suggestions.

Section 5.2
I suggest moving the last paragraph to the first in this instance.  It also
provides a nice high-level overview.  The current paragraph 1&2 flow well
together, hence this order suggestion.

The third paragraph is a really long way of stating that interoperability
is required.  Entities must be able to create, send, receive, and process
data (hence the need for a standard).  It's fine, but could be shorter.

Section 5.3:
OLD:
"One variation of the background-check model is where the Relying Party and
the Verifier on the same machine, and so there is no need for a protocol
between the two."
Proposed:
"One variation of the background-check model is where the Relying Party and
the Verifier are on the same machine, performing both functions together.
In this case, there is no need for a protocol between the two."
I think the addition is necessary or you could scratch your head wondering
why no protocol is needed.  If they are separate functions on the same
system, you'd need some way for the relying party to access the results of
the verifier.

The next sentence could benefit from being made into several.
OLD:
"It is also worth pointing out that the choice of model is generally up to
the Relying Party, and the same device may need to create Evidence for
different Relying Parties and different use cases (e.g., a network
infrastructure device to gain access to the network, and then a server
holding confidential data to get access to that data). As such, both models
may simultaneously be in use by the same device."

If the server holds confidential data, why does it need to create evidence
to access the data?  I'm not following the second example as written, so my
proposed text may not be as intended.

Proposed:
"It is also worth pointing out that the choice of model is generally up to
the Relying Party.  The same device may need to create Evidence for
different Relying Parties and/or different use cases.  For instance, a
network infrastructure device may attest evidence to gain access to the
network or a server holding confidential data  may require attestations of
evidence to gain access to the data. As such, both models may
simultaneously be in use by the same device."

Section 6:
The first 3 sentences are fine, but if you wanted to reduce it, it could be
one sentence.
Current:
"An entity in the RATS architecture includes at least one of the roles
defined in this document. As a result, the entity can participate as a
constituent of the RATS architecture. Additionally, an entity can aggregate
more than one role into itself. "
Proposed:
"An entity in the RATS architecture includes at least one [or more] of the
roles defined in this document. "
Or more is redundant, so that really isn't necessary to convey the same
point.

Then the last sentence:
I'd change it a little from:
"In essence, an entity that combines more than one role also creates and
consumes the corresponding conceptual messages as defined in this document."
To:
"In essence, an entity that combines more than one role may create and
consume the corresponding conceptual messages as defined in this document."

It might not, it could be the verifier and relying party.

Section 5:
Consider changing from:
"That is, it might appraise the trustworthiness of an application
component, or operating system component or service, under the assumption
that information provided about it by the lower-layer hypervisor or
firmware is true. "
To:
"That is, it might appraise the trustworthiness of an application
component, operating system component, or service under the assumption that
information provided about it by the lower-layer hypervisor or firmware is
true. "

Section 7:

I'd say it's really a stronger level of assurance of security rather than a
stronger level of security in the following:
"A stronger level of security comes when information can be vouched for by
hardware or by ROM code, especially if such hardware is physically
resistant to hardware tampering. "

Then with the following sentence,
"The component that is implicitly trusted is often referred to as a Root of
Trust."
I think it would be worth mentioning that a hardware RoT is immutable and
mutable RoTs in software are also possible, offering different levels for
an assurance of trust/security.

Section 9.

Since ROLIE [RFC8322] has been added to SCAP2.0, it would be good to list
that as an option since a lot of time and effort went into how to secure
the exchange of formatted data for that protocol.

Section 11. Privacy
This is a good start.  Remote attestation also provides a way to profile
systems as well as the user behind that system.  If attestation results go
higher in the stack to include containers and applications, it could reveal
even more about a system or user.  The scope of access needs to be
emphasized, including the administrators access to data (or restrictions).
If there is a way to make inferences about attestations from their
processing, that should be noted as well.

Section 12:
This will need to state an explicit requirement for transport encryption.
In the introductory paragraph, the text is as follows:
"Any solution that conveys information used for security purposes, whether
such information is in the form of Evidence, Attestation Results,
Endorsements, or Appraisal Policy, needs to support end-to-end integrity
protection and replay attack prevention, and often also needs to support
additional security protections. For example, additional means of
authentication, confidentiality, integrity, replay, denial of service and
privacy protection are needed in many use cases. "
Proposed:
"Any solution that conveys information used for security purposes, whether
such information is in the form of Evidence, Attestation Results,
Endorsements, or Appraisal Policy must support the security properties of
confidentiality, integrity, and availability.  A conveyance protocol
includes the typical transport security considerations:
o  end-to-end encryption,
o  end-to-end integrity protection,
o  replay attack prevention,
o  denial of service protection,
o  authentication,
o  authorization,
o  fine grained access controls, and
o  logging in line with current threat models and zero trust architectures."


-- 

Best regards,
Kathleen