Original text:
9.  10. The conveyance of Evidence and the resulting Attestation Results also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many <del> use cases. </del>  To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust,

Reviewer comments:
Based on discussion at IETF about including a very high level summary, and text in the arch docs, draft-birkholz-rats-reference-interaction-model, and draft-birkholz-rats-tuda. Signed-off-by: Dave Thaler
A quick review of the strawman, using the strawman to highlight a few points for discussion.

Revised text:
9. <ins> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. To do so, some mechanism of ensuring that the Evidence and Attestation Result are fresh, meaning that there is some degree of assurance that they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, may change immediately after the Evidence or Attestation Result was generated.  The goal is merely to narrow the time window to something the Verifier (for Evidence) or Relying Party (for an Attestation Result) is willing to accept. There are two common approaches to providing some assurance of freshness.  The first approach is that a nonce is generated by a remote entity (e.g., the Verifier for Evidence, or the Relying Party for an Attestation Result), and the nonce is then signed and included along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed after the nonce was generated. A second approach is to rely on synchronized clocks, and include a signed timestamp (e.g., using I.D.draft-birkholz-rats-tuda) along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed at that time, as long as it has some assurance that the timestamp is correct.  This typically requires additional claims about the signer's time synchronization mechanism in order to provide such assurance. In either approach, it is important to note that the actual values in claims might have been generated long before the claims are signed. If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values might have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. </ins> 10. The conveyance of Evidence and the resulting Attestation Results also needs to support additional security protections.  For example, additional means of authentication, confidentiality, integrity, replay, denial of service and privacy protection are needed in many  <ins> use cases.  freshness discusses ways in which freshness can be used in this architecture to protect against replay attacks. </ins> To evaluate the security provided by a particular Appraisal Policy, it is important to understand the strength of the Root of Trust,