I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This draft specifies architectures and terminology for Remote ATtestation procedureS (RATS), which consists of, at a high-level overview, an Attester (which forwards claimant information), Verifier (that analyzes the claims sent from the Attester), and Relying Party (who receives the verification information and determines if the Attester adheres to the relying party’s policy before allowing access/operations to the targeted resource(s)).

The draft also has a privacy section that covers the areas of sensitive data within the architecture; e.g. attestation results: which could consist of the type of firmware/software used, PII, etc.  that the attester is claiming for.  Confidentiality is recommended against these potential types of attacks.  Even if confidentiality is provided, the section goes on to state that information can still be inferred by contextual or timing of the attestor exchange.  The draft doesn’t describe ways to mitigate against this type of attack but should give some guidance.  The section closes out with mitigating against trust with confidential information to the Verifier, in which the Attester can switch roles to a Relying Party where it requests attestation results from the Verifier or claimant information can be attested anonymously.  I believe that the privacy aspects of the draft are comprehensive and mitigations prescribed, except for the contextual and timing attacks, are reasonable.

The security considerations section exists and appropriately defers specific mitigations as this draft is an architectural document devoid of the multitude of use-cases that employ said architecture.  However, the section does provide guidance on the various ways to attack the premise of the architecture: provide a foundation that allows the Relying Party to trust the Attester and their claims.  Areas that are covered in this regards are:

Protecting the attester (on or off device) and their key generation and protection
Protecting message confidentiality, integrity, availability, authentication, authorization, auditing, trustworthiness, and thwarting replay.

I believe that this section, as well, is comprehensive and accurately describes ways of mitigating against the corresponding attacks:

Replay: freshness (e.g. epoch IDs and its limitations against delay attacks thereof (could you list ways of mitigating against delay attacks in section 12.3?))
Trustworthiness: root of trust, secured trust anchors, and sw/hw compartmentalization
CIA: End-to-end protection

which also in turn references relevant RFCs/NIST SP to do so.

General comments:

Thank you for the privacy considerations section.

Editorial comments:

s/comprise Evidence/comprise of Evidence/
s/Section Section 4/Section 4/
s/such caching/such as caching/
s/where the Verifier/whether the Verifier/
s/for ever/forever/