Subject: Re: [Rats] Use case -> architecture document

From: Henk Birkholz <[email-masked]>
Date: Sun, 3 Nov 2019 19:37:04 +0100

Hi Jürgen,

in the RATS WG we split that specific challenge/response interaction 
(there are others, but this is the best understood one) out into this 
document:

> https://datatracker.ietf.org/doc/draft-birkholz-rats-reference-interaction-model/

An complementary approach was recently introduced here:

> https://datatracker.ietf.org/doc/draft-xia-rats-pubsub-model/

Both types of (and by inference - all) interaction adhere to the same 
"attestation principles" (which we are currently relabeled to 
"attestation characteristics" but this is more a matter of finding the 
most intuitive title here), which are included in one of the 
architecture documents.

I think you highlighted a good question that we should put to a call for 
consensus: Are attestation characteristics, such as freshness, 
provenance (often referred to as origination), or veracity defining (or 
vital) concepts for remote attestation procedures so that they belong 
into the architecture document?

Viele Grüße,

Henk

On 15.10.19 17:45, Schönwälder, Jürgen wrote:
> Henk's architecture discusses 'Attestation Principles' that are not in
> Dave's proposal. I guess the WG needs to decide whether to include
> them or not. Are these important for understanding or guiding the RATS
> work?
> 
> I also like to mention that there are research papers where the remote
> attestation process is described more in the form of a challenge
> response interaction, where the verifier sends a specific challenge to
> a device and the device returns a response that is than evaluated by
> the verifier. An example is "compute a hash over certain memory areas
> within a certain time limit" and then the device returns the result
> and the verifier checks whether it is what is expected.  The time
> limit is used to control that an infected device can't reasonably
> forward the challenge to obtain an answer from an unaffected device
> that is then relayed back to the verifier. The question is whether the
> architecture includes models where a stimuli is used to trigger the
> production of a certain Evidence or whether this is left out of the
> architectural picture on purpose. For more details, see for example
> <doi.org/10.1145/2988546> (you will find a preprint if you search).

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Mon, 4 Nov 2019 06:26:55 +0000

Henk,

I prefer having all relevant interaction models in the architecture.

Looking at your architecture draft and "attestation characteristics"
(aka attestation principles), then I am not sure I do understand all
definitions. For me, 'relevance' seems somewhat unclear. Should such
terms be defined in an architecture doccument? Probably yes if they
are fundamental for understanding the technology and not covered by
generally known security terminology.

/js

On Sun, Nov 03, 2019 at 07:37:04PM +0100, Henk Birkholz wrote:
> Hi Jürgen,
> 
> in the RATS WG we split that specific challenge/response interaction (there
> are others, but this is the best understood one) out into this document:
> 
> "attestation principles" (which we are currently relabeled to "attestation
> characteristics" but this is more a matter of finding the most intuitive
> title here), which are included in one of the architecture documents.
> 
> consensus: Are attestation characteristics, such as freshness, provenance
> (often referred to as origination), or veracity defining (or vital) concepts
> for remote attestation procedures so that they belong into the architecture
> document?
> 
> Viele Grüße,
> 
> Henk
> 
> 
> 

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 07 Nov 2019 15:55:50 -0500

> I prefer having all relevant interaction models in the architecture.

Do you want exhaustive details, or just enough to say how things differ and
then reference another document?

    > generally known security terminology.

I agree: the major contribution of an architecture document is a set of
common terms ... for the components of the architecture.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Dave Thaler <[email-masked]>
Date: Thu, 7 Nov 2019 21:01:54 +0000

Michael Richardson wrote:
    > Do you want exhaustive details, or just enough to say how things differ and then reference another document?

Personally I would prefer that any high level info that is solution agnostic be in the arch doc.
And any low level details that are solution specific be in the doc for the specific solution.

Dave

---

From: Schönwälder, Jürgen <[email-masked]>
Date: Thu, 7 Nov 2019 21:05:41 +0000

> then reference another document?

I like to know which interaction models exist and how they differ, I
am fine to leave the gory details that do not impact the architecture
to other documents. (Yes, this is a bit recursive but figuring out
what belongs to an architecture document and what not may require
finding the sweat point where a meaningful cut can be made.)

/js