Draft: draft-ietf-rats-architecture

Commentary: This commit slightly changes the Freshness section to reflect the outcome of the discussion around PR . ( Hopefully I 've managed to capture the gist of Henk 's thinking without disrupting too much the existing flow . ) TL;DR The key change here is the removal of reply protection as a goal in itself . The section now states clearly that the overall goal is instead the identification of the point in time when attestation claims have been signed and/or generated so that a freshness policy can be applied . In this perspective , the fundamental property provided by a nonce - based scheme with regards to freshness is its ability to lock the requester 's clock to the underlying protocol transaction , thus indirectly establishing the epoch of the attestation / verification event . By making the nonce unique and non - predictable , the timeline locking can not be subverted , which provides anti - replay . However , that is a nice side - effect rather than the primary goal . This commit also adds some precision around the nonce and clock properties - unpredictability and trustworthiness respectively . 
 Added consolidated text based on  initial version and review from MCR 
 So , if is dead , can you close it ? 
 Done .
Paragraph (version A):
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 Results are fresh, meaning that there is some degree of
assurance that they still reflect the latest state of the Attester,
and that any Attestation Results were generated using the latest
Evidence and 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, might change immediately after
the Evidence or Attestation Results were 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.
Paragraph (version A):
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.
Paragraph (version A):
A second approach is to rely on synchronized clocks, and include a
signed timestamp (e.g., using I-D.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.
Paragraph (version A):
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.
Paragraph (version B):
A remote entity (Verifier or Relying Party) may need to learn the
point in time (i.e., the "epoch") an Evidence or Attestation Result
has been produced.  This is essential in deciding whether the
included Claims and their values can be considered fresh, meaning
they still reflect the latest state of the Attester, and that any
Attestation Result was generated using the latest Appraisal Policy
for Evidence.
Paragraph (version B):
Freshness is assessed based on a policy defined by the consuming
entity, Verifier or Relying Party, that compares the estimated epoch
against an "expiry" threshold defined locally to that policy.  There
is, however, always a race condition possible in that the state of
the Attester, and the Appraisal Policy for Evidence, might change
immediately after the Evidence or Attestation Result was generated.
The goal is merely to narrow their recentness to something the
Verifier (for Evidence) or Relying Party (for Attestation Result) is
willing to accept.  Freshness is a key component for enabling caching
and reuse of both Evidence and Attestation Results, which is
especially valuable in cases where their computation uses a
substantial part of the resource budget (e.g., energy in constrained
devices).
Paragraph (version B):
There are two common approaches for determining the epoch of an
Evidence or Attestation Result.
Paragraph (version B):
The first approach is to rely on synchronized and trustworthy clocks,
and include a signed timestamp (see I-D.birkholz-rats-tuda) along
with the Claims in the Evidence or Attestation Result.  Timestamps
can be added on a per-Claim basis, to distinguish the time of
creation of Evidence or Attestation Result from the time that a
specific Claim was generated.  The clock's trustworthiness typically
requires additional Claims about the signer's time synchronization
mechanism.
Paragraph (version B):
The time between the creation of Claims and the collection of
Claims is indistinguishable.
Paragraph (version B):
Implicit and explicit timekeeping can be combined into hybrid
mechanisms.  For example, if clocks exist and are considered
trustworthy but are not synchronized, a nonce-based exchange may be
used to determine the (relative) time offset between the involved
peers, followed by any number of timestamp based exchanges.  In
another setup where all Roles (Attesters, Verifiers and Relying
Parties) share the same broadcast channel, the nonce-based approach
may be used to anchor all parties to the same (relative) timeline,
without requiring synchronized clocks, by having a central entity
emit nonces at regular intervals and have the "current" nonce
included in the produced Evidence or Attestation Result.
Paragraph (version B):
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 generated at boot time
might have been saved to secure storage until network connectivity is
established to the remote Verifier and a nonce is obtained.