[Rats] status of draft-ietf-rats-architecture-09.txt

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 05 February 2021 21:07 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CDF6E3A0A79 for <rats@ietfa.amsl.com>; Fri, 5 Feb 2021 13:07:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 80FplYaaWUIL for <rats@ietfa.amsl.com>; Fri, 5 Feb 2021 13:07:42 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4D803A09ED for <rats@ietf.org>; Fri, 5 Feb 2021 13:07:42 -0800 (PST)
Received: from localhost (localhost []) by tuna.sandelman.ca (Postfix) with ESMTP id 9188B3899E for <rats@ietf.org>; Fri, 5 Feb 2021 16:10:41 -0500 (EST)
Received: from tuna.sandelman.ca ([]) by localhost (localhost []) (amavisd-new, port 10024) with LMTP id KymFN2p9IRjM for <rats@ietf.org>; Fri, 5 Feb 2021 16:10:40 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D675638990 for <rats@ietf.org>; Fri, 5 Feb 2021 16:10:40 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7986E8F8 for <rats@ietf.org>; Fri, 5 Feb 2021 16:07:40 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: rats@ietf.org
In-Reply-To: <161254753085.24721.3836651297819593659@ietfa.amsl.com>
References: <161254753085.24721.3836651297819593659@ietfa.amsl.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 05 Feb 2021 16:07:40 -0500
Message-ID: <24831.1612559260@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/993-8As7beiuLqliXRd3-mb433U>
Subject: [Rats] status of draft-ietf-rats-architecture-09.txt
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote ATtestation procedureS <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Feb 2021 21:07:46 -0000

internet-drafts@ietf.org wrote:
    > 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-09.html

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

Hi, the RATS architecture design team has posted this -09 version.
Here is a graph of tickets (issues and pull requests):

The WGLC in November resulted in a number of substantive reviews.
One from Guy resulted in around 50 issues raised.
The review from Thomas and Simon at ARM resulted in fewer tickets, but many
difficult issues.  One of which was to change the ordering of the sections,
and we posted -08 after doing that, so the diff above is after the
The reordering raised the question: to what extent should we use Terminology
prior to defining it? Mostly, yes to forward references, but should it be Capitalized?

Sections on Freshness have been reworked, and the examples (diagrams) in the
appendix A have been reworked, revised, checked, rechecked, etc.
This is associated with new text in the Security Considerations about how
things can go wrong, and what other aspects are important.
(TLS or other equivalent schemes can bring needed non-reordering guarantees, for instance)

https://github.com/ietf-rats-wg/architecture/issues currently shows 23 open issues.
13 are wontfix issues that I will be dealing with in this email.
 4 are has-pull-request issues on relatively minor points that we will iron out,

We think that -09 is largely complete, that the Shepherd write up can
complete, and that it is time for the AD review to start.
We leave it up to the WG chairs to decide if they need another WGLC.
(My opinion is no)

Issues we won't fix:
Endorsements definition is too narrow given PR150 clarification
   A place where we had some disagreement is to the extent that the
   *INFORMATIONAL* *ARCHITECTURE* document needs to specify how Endorsements
   work, given that Endorsements were not generally in scope for
   standardization at this pass of the RATS Architecture.
   We decided that this discussion was a rathole, and thus wontfix.

Endorser / Endorsement optional optimization?
   created term: 'reference value provider', but did not fix entire issue
   consitent with above.

Attester definition (Guy)
   we think that other edits deal with this concern.

Reference use Case -- Roles (Guy)
   the use case/terminology change addressed this concern

Network Endpoint Assessment (Guy)
   We declined to insert a forward reference here

3.2. Confidential Machine Learning (ML) Model Protection (Guy)
   We agree that ML is not different than other software, people think
   confidential data needs to be "encrypted", but that confidential code needs
   to be obfuscated. In fact, both just require confidentiality protection, with
   a similar solution.

Definition of Relying Party in confidential ML model use case
   see above

TAM/TEE use case
   The TAM is not doing the conducting, cf TEEP transport spec

5.2 background-check model plumbing
   We didn't agree with changing the model.

5.2 - RP format issues
   The industry already has multiple formats today. Multiple is important,
   expanding the set indefinitely is not intended or good, but if someone (like
   another SDO) does add another one, RATS can accommodate it.
   "should [attack surface] be compared in all the other variations in this
   document" -> if there's an important requirement that falls out of it
   yes. But I don't know of one. "how do you know it's even true" -> not sure
   what "it" refers to but if it is "minimizing code footprint", then it's true
   that 2 parsers is generally more code than 1 parser (the onus of showing
   otherwise would be on the person arguing that 2 parsers is less code than 1
   parser). "should this one be deleted" -> no.

8.2 Endorsements
   We didn't understand what we should change, and concluded so.

8.3 Attestation Results
   Asks why we have split Relying Party and Verifier, because in a number
   of cases, the RP could make the determination itself.  But the reason
   for the split is due to scaling and heterogeniuty.  We decided that
   the text was clear enough.

use of "entity" and "Artifact" in the Terminolgy Section
   We discussed the use of Artifacts and Entities in the Terminology, given
   that we actually don't really those terms again.
   But, it is precisely because we define more specific terms in those
   sections that we never have to use those words again.

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide