Re: [Rats] Use case -> architecture document

Henk Birkholz <> Tue, 15 October 2019 16:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E06A12012D for <>; Tue, 15 Oct 2019 09:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vtq4sFuQheuy for <>; Tue, 15 Oct 2019 09:24:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B474612010F for <>; Tue, 15 Oct 2019 09:24:45 -0700 (PDT)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id x9FGOdtN028833 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Tue, 15 Oct 2019 18:24:40 +0200
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Tue, 15 Oct 2019 18:24:34 +0200
To: =?UTF-8?B?U2Now7Zud8OkbGRlciwgSsO8cmdlbg==?= <>, Dave Thaler <>
CC: "" <>
References: <> <> <> <> <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Tue, 15 Oct 2019 18:24:30 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Rats] Use case -> architecture document
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Oct 2019 16:24:48 -0000

Hi Jürgen,

a quick reply on the most simple item (I hope):

> challenge response interaction

The authors decided to split solution references out of the architecture 
and at the moment reference interaction models are maintained here:


We are working on the request to move information elements that are not 
Claims but used in the transfer protocols to this I-D, too.

There is also running code as a "proof of concept on freshness & 
veracity" for the nonce-based handshake to enable some hand-on experience:


The next steps are to include more interaction are to include additional 
interaction models for DICE, DAA & TUDA (and corresponding minimal sets 
of elements for network protocols).

Viele Grüße,


On 15.10.19 17:45, Schönwälder, Jürgen wrote:
> On Mon, Oct 14, 2019 at 11:01:04PM +0000, Dave Thaler wrote:
>> As requested, I have written a document for the WG to consider, that
>> includes my architectural patterns work, plus some content pulled from
>> others' docs.  It's not complete (i.e., some stuff is not covered), but I do
>> hope it's readable by a general audience.
> This document is well readable and the use case examples seem to be
> about right (although it is not entirely clear for all of them how the
> architecture supports them). Dave's document defines fewer terms
> compared to Henk's document and I assume the WG needs to decide what
> the set of terms is that should be defined in the WG's architecture
> document.
> Dave takes a minimalist approach, but then he introduces some terms
> later on in the document (e.g., Endorsement) that may actually belong
> into the terminology section.
> If an Endorsement is a statement, why is it defined under Conceptual
> Messages? I assume messages may carry endorsements.  Perhaps the
> section title "Conceptual Messages" is a bit misleading?  Henk's
> document uses the term 'claim' (which does not really show up in
> Dave's document), as a superclass, i.e., Endorsements and Evidence are
> all forms of Claims (instead of 'Conceptual Messages'). Perhaps Dave's
> 'statements' used informally in the 'Conceptual Messages' section are
> Henk's 'claims' and we need to pick a term and then change the section
> title to 'Types of Claims' or 'Types of Statements' or something like
> that and we likely want to define the concept of a 'Claim' or
> 'Statement'.
> 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
> <> (you will find a preprint if you search).
> /js