[Last-Call] Secdir last call review of draft-ietf-rats-architecture-21

[Shawn Emery via Datatracker <[e-mail]>]

Reviewer: Shawn Emery
Review result: Has Nits

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/