Draft: draft-ietf-rats-architecture

Commentary: The review is at : 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 do n't think that the architecture can do this . Other typos handled .
Mailing list commentary: 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 ) , ( 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 does n’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/
Paragraph (version A):
Typically, a solution starts with a specific component (sometimes
referred to as a root of trust) that often provides trustworthy
device identity, and performs a series of operations that enables
trustworthiness appraisals for other components.  Such components
perform operations that help determine the trustworthiness of yet
other components, by collecting, protecting or signing measurements.
Measurements that have been signed by such components comprise
Evidence that when evaluated either supports or refutes a claim of
trustworthiness.  Measurements can describe a variety of attributes
of system components, such as hardware, firmware, BIOS, software,
etc.
Paragraph (version B):
Typically, a solution starts with a specific component (sometimes
referred to as a root of trust) that often provides trustworthy
device identity, and performs a series of operations that enables
trustworthiness appraisals for other components.  Such components
perform operations that help determine the trustworthiness of yet
other components, by collecting, protecting or signing measurements.
Measurements that have been signed by such components are comprised
of Evidence that when evaluated either supports or refutes a claim of
trustworthiness.  Measurements can describe a variety of attributes
of system components, such as hardware, firmware, BIOS, software,
etc.
Paragraph (version A):
As explained in terminology, there are a variety of roles in the RATS
architecture and they are defined by a unique combination of
artifacts they produce and consume.  Conversely, artifacts are also
defined by the roles that produce or consume them.  To produce an
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
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.
Paragraph (version B):
As explained in terminology, there are a variety of roles in the RATS
architecture and they are defined by a unique combination of
artifacts they produce and consume.  Conversely, artifacts are also
defined by the roles that produce or consume them.  To produce an
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
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.