Re: [EAT] [Rats] Introduction

AndreRein <> Mon, 10 September 2018 10:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 31B66130E70; Mon, 10 Sep 2018 03:21:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nIKDu30wbyS2; Mon, 10 Sep 2018 03:21:40 -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 3F01D130E71; Mon, 10 Sep 2018 03:21:39 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id 19F9C260E158C; Mon, 10 Sep 2018 11:21:36 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 10 Sep 2018 11:21:37 +0100
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Mon, 10 Sep 2018 12:21:32 +0200
From: AndreRein <>
To: Laurence Lundblade <>, Shawn Willden <>
CC: "" <>, Carsten Bormann <>, "" <>
Thread-Topic: [Rats] [EAT] Introduction
Thread-Index: AQHURqZ/KHFfJeeWREqr9RtZ+w7bSaTktPwAgANTDICAAUh8YA==
Date: Mon, 10 Sep 2018 10:21:31 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6BA94F08BDCB8E44B30675B3FF1834712242C6DAFRAEML521MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [EAT] [Rats] Introduction
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: EAT - Entity Attestation Token <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Sep 2018 10:21:43 -0000

From my perspective you are right that the current discussions around (remote) attestation are very TCG shaped and in general a TPM is often regarded as _the_ security anchor. In a way this makes a lot of sense, because the TPM offers a secure identity (Root of Trust for Reporting (RTR)) and a tamper-proof storage (Root of Trust for Storage (RTS)), both of which are required for an attestation process (at least how it is generally understood today). However, it is important to note that the measurements themselves are not performed by the TPM; the TPM is only used for the secure recording and reporting of measured values during the attestation. Depending on which parts of the system are to be attested, the actual measurements are provided by other (secure) components, starting from an initial (trusted) measurement component (Root of Trust for Measurement (RTM)).

I don't want to go too much into the technical details here, but I think it makes sense for a general specification of an attestation (and a corresponding protocol) to detach itself from the TPM as a term (I'm not saying that we do this actually) and instead argue on the basis of the RoTs involved. A TPM is an excellent reference implementation that provides certain RoTs in a very secure way, but a TPM provides only one implementation possibility that realizes parts of what is necessary to report a system’s state for conducting a (remote) attestation procedure.

Best regards,


From: RATS [] On Behalf Of Laurence Lundblade
Sent: Sonntag, 9. September 2018 18:38
To: Shawn Willden <>
Cc:; Carsten Bormann <>rg>;
Subject: Re: [Rats] [EAT] Introduction

My understanding from the RATS BoF and talking to Henk, Marty and others is that it is about sending the attestations created by TPMs to a remote entity. These  attestation messages contain the usual measurements of the running SW that TPMs do. It is very TCG oriented.

There is some possibility of defining a protocol to carry these attestations, but I don’t think anything has been written.

There was a lot of interest in this from the network infrastructure folks that want to make sure routers, firewalls and such were booted and still running correctly.


On Sep 7, 2018, at 6:51 AM, Shawn Willden <<>> wrote:

Thanks. I need to get clear on what rats@ is about. Is there a draft?

On Fri, Sep 7, 2018 at 6:29 AM Carsten Bormann <<>> wrote:
On Sep 6, 2018, at 18:37, Shawn Willden <<>> wrote:
> Please excuse me if I'm violating some list etiquette with this introduction; it seemed like the best way to jump in. It appears that cross-posting between RATS and EAT is fairly common, so I think I'm good on that front :-)

Hi Shawn,

welcome to this discussion!

Indeed, as long as we are trying to find out what is what between eat@ and rats@, cross-posting is the way to go.

A thread of three of the messages triggered by your initial message went to eat@ only, though:

Archived-At: ⁨<>⁩
Archived-At: ⁨<>⁩
Archived-At: ⁨<>⁩

As these are essentially about rats@ content (proof of protection), it would be useful for rats@ people to read them, too (and then reply to both lists, please).

Grüße, Carsten
Shawn Willden | Staff Software Engineer |<> | 801-477-4296
EAT mailing list<>