Re: [Rats] disposition of remaining pull requests to architecture document

Laurence Lundblade <lgl@island-resort.com> Fri, 11 September 2020 17:32 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D70173A1562 for <rats@ietfa.amsl.com>; Fri, 11 Sep 2020 10:32:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNAEbY2cnzcg for <rats@ietfa.amsl.com>; Fri, 11 Sep 2020 10:32:55 -0700 (PDT)
Received: from p3plsmtpa12-07.prod.phx3.secureserver.net (p3plsmtpa12-07.prod.phx3.secureserver.net [68.178.252.236]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42C083A0E22 for <rats@ietf.org>; Fri, 11 Sep 2020 10:32:55 -0700 (PDT)
Received: from laurences-mbp.lan ([63.225.87.1]) by :SMTPAUTH: with ESMTPA id GmurkbYVoSWkgGmuskuAIC; Fri, 11 Sep 2020 10:32:54 -0700
X-CMAE-Analysis: v=2.3 cv=bt8y+3Si c=1 sm=1 tr=0 a=zts2ur/HCa1gw63mIQw/Dg==:117 a=zts2ur/HCa1gw63mIQw/Dg==:17 a=IkcTkHD0fZMA:10 a=l70xHGcnAAAA:8 a=0XtbOteLAAAA:20 a=jfbWen5HAAAA:8 a=48vgC7mUAAAA:8 a=1UnYx_B0sqbURrX4g4gA:9 a=NDWdHiM6gX_rdbw8:21 a=KvnVzugAF64E8XEK:21 a=QEXdDO2ut3YA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=WkL3c-inM1szph94ijzX:22 a=w1C3t2QeGrPiZgrLijVG:22
X-SECURESERVER-ACCT: lgl@island-resort.com
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Laurence Lundblade <lgl@island-resort.com>
In-Reply-To: <5786.1599579936@localhost>
Date: Fri, 11 Sep 2020 10:32:53 -0700
Cc: rats@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B6B67BD-800C-4A42-9AD6-6F92E0663207@island-resort.com>
References: <5786.1599579936@localhost>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-CMAE-Envelope: MS4wfIZxV9cNWuWb2DGIf2Uf5NY6jjg8PZrujLuh2+4JXaCKnEDj+N8iSdHXZ+OjXbePCsatfz83kDV8r5D/e2cATfIi36tBAmJJEVcllLf+46TLpM7ocPpF NnQwzXJ90E7I5OzRzFXyF/NyKyAaRBfaFF4wDCT4qqEhi7OGo74btBr1Gsp4Eb80TLMJu3jwqz6T9b+pstk0MUOYYu6MP7yKSg4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/s7xl6knjZ7PenoiQHz1fr3udEvE>
Subject: Re: [Rats] disposition of remaining pull requests to architecture document
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, 11 Sep 2020 17:32:58 -0000


> On Sep 8, 2020, at 8:45 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> NO DESIGN TEAM MEETING September 15, due to conflicts (ADD virtual interim,
> other things).   Next meeting is September 22.
> 
> Pull request #130 -- https://github.com/ietf-rats-wg/architecture/pull/130
>  The DT felt that the changes focused too much on PII, and removed many
>  other aspects of privacy from the text.  We couldn't come up with a
>  word smithing way to fix this, so we suggest reviewing the suggestions
>  and maybe starting over.

I wrote this to help with Kathleen’s comments, but have no strong motivation for it. I will perhaps update it after I get through some other stuff. Don’t hold your breath.

> 
> Pull request #94 -- https://github.com/ietf-rats-wg/architecture/pull/94
>  Many people on the DT preferred the old text.
>  It's been three months without progress or revision.
>  We did not understand the goals of these changes, the defects in the
>  existing text, so we couldn't find a different phraseing.
>  "wontfix"

I will probably make another attempt at a PR here, probably different from this one.

> 
> Pull request #141 -- https://github.com/ietf-rats-wg/architecture/pull/141
>  After some arguments over trailing periods.... we recognized that the goal
>  of this effort was to find places to make reference to the Reference Values
>  (but also cf: https://www.gocomics.com/bloom-county/2015/10/01 )
> 
>  DThaler will lead a PR that makes Reference Values more prominent.
>  I edited the digram to form:
>    https://github.com/ietf-rats-wg/architecture/pull/147/files
>  I see it needs a bit more care.  The new term "reference value provider"
>  was disliked by all, but it was 2 minutes to the end of the meeting.

Yes, the reference values was the main motivation in my change. Glad you settled the periods issue without me. :-)

> 
> Dear WG chairs, WGLC soon?

I have two open issues against section 7 that I think are important. I generally think section 7 needs a fair bit of work. 

One of the issues with it is intermingling primary trust flow vs the secondary trust flow. Primary trust flow is about the RP trusting the Attesters, the main point of attestation. Secondary is primarily about confidentiality while achieving the primary goal of attestation. I think every subsection of section 7 needs to address both and be clear which it is addressing when it does. I think TLS is good enough for the confidentiality in the secondary trust flow; attestation can be used, but is not needed.

The other issue with section 7 is that I think it needs to say that Verifier trust in an Attester is almost always about attestation keys and that is it transitive through the Endorser. The only case where it is not is when they are connected by trusted HW, for example on the same bus, and that is usually not the reason to deploy attestation.

Also, I think the distinction between Attestation and TLS/HTTPS needs to be described in the document. Say why we need Attestation given we have TLS.

I added a new PR with with an Appendix B with System Examples that I think is very helpful.

I will keep working on PRs to address these, but it won’t happen super quick. It doesn’t have to be me addressing them. I realize I may be in the rough on some of these, but this is my thought on how close to done this is.

I suppose this can go out to the main WG and these things can get addressed there. 

LL


> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>           Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats