Change:
The review is at: URL The review is positive, but asks for: `
I'm not sure how, in an abstract architecture, we can mitigate against timing attacks. A specific protocol could propose mechanisms to defeat traffic analysis, but I don't think that the architecture can do this. Other typos handled. 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 ?)) 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/

Discussion:
trustworthiness appraisals for other components.  Such components perform operations that help determine the trustworthiness of yet other components, by collecting, protecting or signing measurements. <del> Measurements that have been signed by such components comprise Evidence that when evaluated either supports or refutes a claim of </del> <ins> Measurements that have been signed by such components are comprised of Evidence that when evaluated either supports or refutes a claim of </ins> trustworthiness.  Measurements can describe a variety of attributes of system components, such as hardware, firmware, BIOS, software, etc.

artifact means that a given role introduces it into the RATS architecture.  To consume an artifact means that a given role has responsibility for processing it in the RATS architecture.  Roles <del> also have the ability to perform additional actions such caching or forwarding artifacts as opaque data.  As depicted in overview, these additional actions can be performed by several roles. </del> <ins> also have the ability to perform additional actions such as caching or forwarding artifacts as opaque data.  As depicted in overview, these additional actions can be performed by several roles. </ins> 4.