Re: [Rats] Use case -> architecture document

Laurence Lundblade <lgl@island-resort.com> Thu, 10 October 2019 18:45 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 63CB2120827 for <rats@ietfa.amsl.com>; Thu, 10 Oct 2019 11:45:49 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 xymPrwZE7lve for <rats@ietfa.amsl.com>; Thu, 10 Oct 2019 11:45:47 -0700 (PDT)
Received: from p3plsmtpa06-09.prod.phx3.secureserver.net (p3plsmtpa06-09.prod.phx3.secureserver.net [173.201.192.110]) (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 63590120813 for <rats@ietf.org>; Thu, 10 Oct 2019 11:45:47 -0700 (PDT)
Received: from [10.15.0.14] ([45.56.150.64]) by :SMTPAUTH: with ESMTPA id IdRYi9nhy4rZ1IdRYihCmy; Thu, 10 Oct 2019 11:45:45 -0700
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <10785046-544F-4406-BEC0-A138254FEAC8@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_554D4C5B-039B-4837-BABF-6272057AF5B7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 10 Oct 2019 11:45:44 -0700
In-Reply-To: <CAHbuEH4RQNWh8GHPsi51_gZexKpi5KXagQvTe7tQgemHcqGY7Q@mail.gmail.com>
Cc: Carsten Bormann <cabo@tzi.org>, "Xialiang (Frank, Network Standard & Patent Dept)" <frank.xialiang@huawei.com>, Juergen Schoenwaelder <J.Schoenwaelder@jacobs-university.de>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "rats@ietf.org" <rats@ietf.org>
References: <CAHbuEH7f0jjquR=iZDgof4DkgpZKgxEP86NcQ0A1NQ=SP+_FHA@mail.gmail.com> <C02846B1344F344EB4FAA6FA7AF481F13E9560C0@dggemm511-mbx.china.huawei.com> <CAHbuEH7WkqeyUW3sL5bdw5N25B6O7ZEF0Qkx03fE5c42Sd4M5w@mail.gmail.com> <b91baad2-2fc3-a5e4-6898-e2cddcda300d@sit.fraunhofer.de> <20191009145006.r2pjsoo6jxirah64@anna.jacobs.jacobs-university.de> <CAHbuEH6u-6GsJjK8s0eFQPLeSuGjPMgonhyQkmaeA6Q+rp42kA@mail.gmail.com> <203F8673-A9B0-446B-966B-1FD05A5C2D41@tzi.org> <CAHbuEH4RQNWh8GHPsi51_gZexKpi5KXagQvTe7tQgemHcqGY7Q@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-CMAE-Envelope: MS4wfFz/GWb2fe5tBziF2qIB0ufRUpOp492J9TH28YCNK0HO1Z9O01wd8I5HPoPxeTNGIHMLBDRHeMKv2BHaAW/digSH4A4GQOAhpY2HsacX0/otAwbYDGAU qDqDEhgf+Nu+qPhn1iAl69/n536HX94UdAojrTSgzqwDSUFaWR8Mi8HaqJq7nsFTRs0s6JGYsjfoc37Q81CbR+pNYUXVAW5doj6T+JkqWt3q6W7kI09KZM/I AzibdEsyjpRijoauRF8FQinTFRLM7XRwFsi//XFX8TvmmjodFx/kk3cFmA1Y1Cl9SRkWhFu3KUyPrwHSGzKdyGqaGRwYn2dCcAXEDjYGMPqUyh/YlPhmk8OT KcaIBQyo2u6wLN+kRvGmQ9Za76g5lg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/NHwAL5yfA4JDT-pubYMa8Ko9_i4>
Subject: Re: [Rats] Use case -> 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: Thu, 10 Oct 2019 18:45:56 -0000

I know Henk has put lots of work into this. Here’s some hopefully concrete and helpful comments on why it is hard for me to read.

I think this work is hard because we have different well-establishes worlds (TCG, TEE, router/Yang, mobile apps worlds) coming together that have been unconsciously using terminology in very particular ways for a long time. Coming to common terminology seems important.


In the intro:
The long-standing Internet Threat Model [RFC3552] focuses on threats to the communication channel, as pioneered by Dolev and Yao [DOLEV-YAO] in 1983. However, threats to the endpoint [RFC5209] and system components [RFC4949] of transited communication gear (i.e. hosts) are increasingly relevant for assessing the trustworthiness properties of a communication channel. Beyond the collection and conveyance of security posture [RFC5209] about an endpoint (host), remote attestation provides believable trustworthiness claims ("Evidence") about an endpoint (host). In general, this document provides normative guidance how to use, create or adopt network protocols that facilitate RATS.

This sentence about transited gear and trusting the channel is confusing. Is the gear in moving around or is something moving through the gear? It is hard to tell from the sentence. I don’t think we are assessing communication channels, so mention of them seems both wrong and extraneous.
Mention of NEA [RFC5209] is probably not needed in the introduction. The way it is introduced, you have to follow the link to know what the  sentence is trying to say unless you happen to know that 5209 is NEA and what NEA is.
The last sentence could probably be left off.


First bullet in 1.1:

   o  In remote attestation workflows, trustworthiness Claims are
      accompanied by a proof of veracity.  Typically, this proof is a
      cryptographic expression such as a digital signature or message
      digest.  Trustworthiness Claims with proof is what makes
      attestation Evidence believable.

Claims haven’t been properly introduced at this point in the document
The word “workflow” is unnecessary. 
The adjective “trustworthiness” applied to claims is unnecessary and confusing. Are they different from untrustworthy claims?
“proof of veracity” and “cryptographic expression” are bonus technical terms that don’t help.
Instead of the whole paragraph: “Claims are digitally signed to prove their origin” (yes, they can be MAC’d, but it is very untypical and the intro doesn’t need to be burdened mentioning it).


Some of the sources of difficult readability are:
Use of lots of extra and varying technical terms for roughly the same thing. For example “proof of veracity”, “cryptographic expression”. 
Out of order introduction of concepts and terminology. For example, “claim” is used before being described. 
Extraneous words and framing. 
It feels like each sentence or paragraph is trying to say too much.
Lots of abstraction and few easy-to-relate-to examples.

LL