[Rats] RATS Architecture Document Review

[Kathleen Moriarty <[e-mail]>]

Greetings!

I reviewed the RATS Architecture document with the intent of progressing
this to last call soon as the document shepherd.  The document has come a
long way since my first and second detailed reviews, thank you all very
much for all the work that has been put into this document!

Here is my current set of comments, which do not include the Appendix.  I
will have to read that in the next few days.

This should be quick to get through as text is suggested in most cases, it
may appear long, but really is not.

IETF RATS Architecture Review

Abstract:
The abstract limits remote attestation to network protocols and assessing
peers.  A major use for it will be posture assessment, which could be a
management station that collects and verifies the evidence.  Let's work
this into the abstract so that the solution is not viewed as constrained as
the abstract suggests.  How about:

OLD:
 In network protocol exchanges it is often the case that one entity
   requires believable evidence about the operational state of a remote
   peer.  Such evidence is typically conveyed as claims about the peer's
   software and hardware platform, and is subsequently appraised in
   order to assess the peer's trustworthiness.  The process of
   generating and appraising this kind of evidence is known as remote
   attestation.  This document describes an architecture for remote
   attestation procedures that generate, convey, and appraise evidence
   about a peer's operational state.

NEW:
   It is often the case that one entity
   requires believable evidence about the operational state of a remote
   peer.  Such evidence is typically conveyed as claims about the peer's
   software and hardware platform, and is subsequently appraised in
   order to assess the peer's trustworthiness.  The process of
   generating and appraising this kind of evidence is known as remote
   attestation.  This document describes an architecture for remote
   attestation procedures that generate, convey, and appraise evidence
   about a peer's operational state.

Introduction:
NIT: RATS is provided as an acronym and used, but then the text reverts
back to the expanded text.  Choose how you'd like to do this an be
consistent.

Section 2.1:
NIT:
Network operators is too limited as others want this information as well.
Suggest changing
S/Network operators/Organizations/
OLD:
Network operators want a trustworthy report that includes identity
   and version information about the hardware and software on the
   machines attached to their network, for purposes such as inventory,
   audit, anomaly detection, record maintenance and/or trending reports
   (logging).
NEW:
Organizations want a trustworthy report that includes identity
   and version information about the hardware and software on the
   machines attached to their network, for purposes such as inventory,
   audit, anomaly detection, record maintenance and/or trending reports
   (logging).
OLD:
The network operator may also want a policy by which full
   access is only granted to devices that meet some definition of
   hygiene, and so wants to get Claims about such information and verify
   its validity.
NEW:
An operator may also want a policy by which full
   access is only granted to devices that meet some definition of
   hygiene, and so wants to get Claims about such information and verify
   its validity.

If this should be more generally readable, then removing the network focus
here would help a general reader who might be concerned with lateral
movement between applications rather than "access to the network".  We no
longer advise a mushy core (e.g. zero trust architecture), so I suggest the
following word changes:

OLD:
Remote attestation is desired to prevent vulnerable or
   compromised devices from getting access to the network and
   potentially harming others.
NEW:
Remote attestation is desired to prevent vulnerable or
   compromised devices from gaining further access and
   potentially harming others.

Section 11:
NIT:
Remove the closing paren in the second paragraph as there is no opening
parentheses.
"Many claims in Attestation Evidence and Attestation Results are
   potentially Personally Identifying Information) depending"

The privacy section should also include a requirement for transport
security protections via TLS, cTLS, DTLS, EDHOC/OSCOAP, IPsec to ensure
only the intended party can access the content (unless that intended party
has been compromised).

Section 12.1.1:
It might be worth calling out that this process could all occur on a single
system.  It reads as if that's the case for this section and you'll have an
IESG with diverse backgrounds reading this.

This seems to be conflating use cases for cryptography:
"Cryptography can also be used to support confidentiality, but keys
   that are used to then provision attestation keys must somehow have
   been provisioned securely beforehand (a recursive problem)."
It would be good to separate out encryption for transport and cryptographic
protections for attestation at the object level or even the attestation
keys for signing processes.  It would be important to have this read well.
You could mention transport level encryption, then a discussion on
attestation keys and options for advanced provisioning (by hand is
certainly an option for secure systems or mention the burn in process for
TPMs by the manufacturer as an example.
Perhaps include an example of how attestation keys might be provisioned to
a TEE for use cases where the TEE is the attester.

Section 12.2
Integrity protections should mention digital signatures over the evidence
for the attestation.  It may be obvious to the authors, but not to all
readers.  This should come before the other mentioned protections.  The
first sentence should be split in two to make this possible and to shorten
the sentence.
OLD:
 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 end-to-end
   integrity protection and replay attack prevention, and often also
   needs to support additional security properties, including:
NEW:
 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 end-to-end
   integrity protection and replay attack prevention.  Cryptographic
digital
signatures provide integrity protection, enabling verification that the
data has not been altered since it was signed.  Solutions often
   need to support additional security properties, including:

A leap is made to the following paragraph and the reader will have trouble
figuring out why it's there.  Tie the following to an explanation of how
one might know this information on whether the RoT is mutable or not and
explain the cryptographic keys and functions are stored/performed in the
RoT, digital signatures are applied within the RoT.  This will explain the
relevance to the integrity section.

"   To assess the security provided by a particular appraisal policy, it
   is important to understand the strength of the root of trust, e.g.,
   whether it is mutable software, or firmware that is read-only after
   boot, or immutable hardware/ROM.

   It is also important that the appraisal policy was itself obtained
   securely.  If an attacker can configure appraisal policies for a
   Relying Party or for a Verifier, then integrity of the process is
   compromised."

12.3:
Make sure the text on transport encryption is added and fuller explanations
on when you may or may not need transport encryption.  It can be in the
other section where I pointed this out and then put a reference to it from
this text:
  "To mitigate this threat, the transport should be at least integrity
   protected and provide origin authentication."

In a coherent section, discuss the physical security options, use cases
within a single system, protected and physically isolated networks, and
then any other use case requiring transport encryption.

-- 

Best regards,
Kathleen