Draft: draft-ietf-rats-architecture

Commentary: Per last week 's design team discussion . Signed - off - by :   
 In general , I like the re - introduction of the " timekeeping " subsections a lot . +1
Paragraph (version A):
Freshness is assessed based on the Appraisal Policy for Evidence or
Attestation Results, 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 policies 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.  Some
flexibility on the freshness requirement, however, 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 A):
There are two common approaches for determining the epoch of an
Evidence or Attestation Result.
Paragraph (version A):
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):
Freshness is assessed based on the Appraisal Policy for Evidence or
Attestation Results 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 policies 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.  Some
flexibility on the freshness requirement 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 three common approaches for determining the epoch of
Evidence or an 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 also 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 A):
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):
A third approach relies on having epoch "handles" periodically sent
to both the sender and receiver of Evidence or Attestation Results by
some "Handle Distributor".
Paragraph (version B):
Handles are different from nonces as they can be used more than once
and can even be used by more than one entity at the same time.
Handles are different from timestamps as they do not have to convey
information about a point in time, i.e., they are not necessarily
monotonically increasing integers.
Paragraph (version B):
Like the nonce approach, this allows associating a "rough" epoch
without requiring a reliable clock or time synchronization in order
to generate or appraise the freshness of Evidence or Attestation
Results.  Only the Handle Distributor requires access to a clock so
it can periodically send new epoch handles.
Paragraph (version B):
The most recent handle is included in the produced Evidence or
Attestation Results, and the appraising entity can compare the handle
in received Evidence or Attestation Results against the latest handle
it received from the Handle Distributor to determine if it is within
the current epoch.  An actual solution also needs to take into
account race conditions when transitioning to a new epoch, such as by
using a counter signed by the Handle Distributor as the handle, or by
including both the current and previous handles in messages and/or
checks, by requiring retries in case of mismatching handles, or by
buffering incoming messages that might be associated with a handle
that the receiver has not yet obtained.
Paragraph (version B):
Whereas the nonce approach typically requires the appraising entity
to keep state for each nonce generated, the handle approach minimizes
the state kept to be independent of the number of Attesters or
Verifiers from which it expects to receive Evidence or Attestation
Results, as long as all use the same Handle Distributor.
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.
Paragraph (version A):
Handles are a third option to establish time-keeping next to nonces
or timestamps.  Handles are opaque data intended to be available to
all RATS roles that interact with each other, such as the Attester or
Verifier, in specified intervals.  To enable this availability,
handles are distributed centrally by the Handle Distributor role over
the network.  As any other role, the Handle Distributor role can be
taken on by a dedicated entity or collapsed with other roles, such as
a Verifier.  The use of handles can compensate for a lack of clocks
or other sources of time on entities taking on RATS roles.  The only
entity that requires access to a source of time is the entity taking
on the role of Handle Distributor.
Paragraph (version A):
Handles are different from nonces as they can be used more than once
and can be used by more than one entity at the same time.  Handles
are different from timestamps as they do not have to convey
information about a point in time, but their reception creates that
information.  The reception of a handle is similar to the event that
increments a relative tickcounter.  Receipt of a new handle
invalidates a previously received handle.
Paragraph (version A):
In this example, Evidence generation based on received handles always
uses the current (most recent) handle.  As handles are distributed
over the network, all involved entities receive a fresh handle at
roughly the same time.  Due to distribution over the network, there
is some jitter with respect to the time the Handle is received,
time(HR), for each involved entity.  To compensate for this jitter,
there is a small period of overlap (a specified offset) in which both
a current handle and corresponding former handle are valid in
Evidence appraisal: "validity-duration = time(HR'_v) + offset -
time(HR_v)".  The offset is typically based on a network's round trip
time.  Analogously, the generation of valid Evidence is only
possible, if the age of the handle used is lower than the validity-
duration: "time(HR_v) - time(EG_a) < validity-duration".
Paragraph (version B):
The following example illustrates a hypothetical Passport Model
solution that uses handles instead of nonces or timestamps.  In this
example, Evidence generation based on received handles always uses
the current (most recent) handle.  As handles are distributed over
the network, all involved entities receive a fresh handle at roughly
the same time.  Due to distribution over the network, there is some
jitter with respect to the time the Handle is received, time(HR), for
each involved entity.  To compensate for this jitter, there is a
small period of overlap (a specified offset) in which both a current
handle and corresponding former handle are valid in Evidence
appraisal: "validity-duration = time(HR'_v) + offset - time(HR_v)".
The offset is typically based on a network's round trip time.
Analogously, the generation of valid Evidence is only possible, if
the age of the handle used is lower than the validity-duration:
"time(HR_v) - time(EG_a) < validity-duration".