Subject: [Rats] I-D Action: draft-ietf-rats-architecture-14.txt

From: [email-masked]
Date: Thu, 09 Dec 2021 10:18:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Remote ATtestation ProcedureS WG of the IETF.

        Title           : Remote Attestation Procedures Architecture
        Authors         : Henk Birkholz
                          Dave Thaler
                          Michael Richardson
                          Ned Smith
                          Wei Pan
	Filename        : draft-ietf-rats-architecture-14.txt
	Pages           : 52
	Date            : 2021-12-09

Abstract:
   In network protocol exchanges it is often useful for one end of a
   communication to know whether the other end is in an intended
   operating state.  This document provides an architectural overview of
   the entities involved that make such tests possible through the
   process of generating, conveying, and evaluating evidentiary claims.
   An attempt is made to provide for a model that is neutral toward
   processor architectures, the content of claims, and protocols.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rats-architecture/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-rats-architecture-14.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-architecture-14

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Dec 2021 14:38:58 -0500

>https://www.ietf.org/rfcdiff?url2=draft-ietf-rats-architecture-14

This revision is mostly the result of Roman's AD review feedback.
You can see the list of closed pull requests at:
  https://github.com/ietf-rats-wg/architecture/pulls?q=is%3Apr+created%3A%3E2021-10-01

Roman's review is at:
  https://mailarchive.ietf.org/arch/msg/rats/V0tee4ohWoSzR6xGqu92GXuZneA/

As detailed at: https://mailarchive.ietf.org/arch/msg/rats/rdnJlehvi1oeEPOsAK9kydWW8a8/
These were turned into issues.  They are are closed now.  You can see them
at: https://github.com/ietf-rats-wg/architecture/issues?q=is%3Aissue+created%3A%3E2021-11-01

Those marked "has-pull-request" were dealt with using the references pull
request. Those marked "wontfix" will be dealt with a reply to Roman's
original message (coming in a few minutes), explaining the design team's thinking.

Many of the issues were dealt using some small wordsmitthing.
We don't think that there any substantial changes to the document or
architecture as the result, just better explanation.

1) in many cases we clarified that integrity of policies, trust stores,
   reference values, evidence is critical.
   basically: if bad actors can change stuff in your verification systems,
   then they probably win.
   (Apply RATS recursively)

2) we asked the WG if it throught that the contents of the trust store were
   read sensitive.
   https://mailarchive.ietf.org/arch/msg/rats/cIkrRWghQQYcrAkf8bl5cvgU2kI/

3) add reference to RFC6024
4) reference RFC4086 for key generation
5) clarify that Attestation Results can contain PII

6) added paragraph explaining why Freshness section is so detailed

I'm including this here too:

    This section provides a number of details.
    It does not however define any protocol formats, the interactions shown are abstract.
    This section is intended for those creating protocols and solutions to
    understand the options available to ensure freshness.
    The way in which freshness is provisioned in a protocol is an architectural decision.
    Provisioning of freshness has an impact on the number of needed round
    trips in a protocol, and therefore must be made very early in the
    design.
    Different decisions will have significant impacts on resulting
    interoperability, which is why this section goes into sufficient detail
    such that choices in freshness will be compatible across interacting
    protocols, such as depicted in {{multievidence_diag}}.

(send pull request if you want to word-smith further)

7) changes to privacy considerations for conceptual messages
8) clarify that claims are collected in a trustworthy manner

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide