Re: [Rats] Definition of an Attesting Environment (and layered attestation)

Laurence Lundblade <lgl@island-resort.com> Wed, 14 July 2021 04:56 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 6739C3A0D5A for <rats@ietfa.amsl.com>; Tue, 13 Jul 2021 21:56:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-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 cZs3Km58BWVs for <rats@ietfa.amsl.com>; Tue, 13 Jul 2021 21:56:04 -0700 (PDT)
Received: from p3plsmtpa07-03.prod.phx3.secureserver.net (p3plsmtpa07-03.prod.phx3.secureserver.net [173.201.192.232]) (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 52C663A0D58 for <rats@ietf.org>; Tue, 13 Jul 2021 21:56:04 -0700 (PDT)
Received: from [192.168.0.100] ([71.92.144.145]) by :SMTPAUTH: with ESMTPSA id 3WwEmimIdVya83WwFmGhrz; Tue, 13 Jul 2021 21:56:03 -0700
X-CMAE-Analysis: v=2.4 cv=CJzv4TnD c=1 sm=1 tr=0 ts=60ee6e63 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:117 a=E5cCtQzjhQJ5yJ7bKjC7Hg==:17 a=QyXUC8HyAAAA:8 a=abMKRnGSH4kTpiEvJp4A:9 a=QEXdDO2ut3YA:10 a=o3v7bOj2j0HKlKJq:21 a=_W_S_7VecoQA:10
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Message-Id: <B525A1CF-C9CE-46DC-BCCD-BF3BE6684A22@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_961EE4D9-52DE-4557-88C5-850E570D81E4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Tue, 13 Jul 2021 21:56:02 -0700
In-Reply-To: <A998AEAF-3E1C-480A-866D-410D0B0D4362@intel.com>
Cc: Thomas Fossati <tho.ietf@gmail.com>, "rats@ietf.org" <rats@ietf.org>
To: "Smith, Ned" <ned.smith@intel.com>
References: <617FC3B4-5C1B-4D35-BD4B-9AC2D1362930@island-resort.com> <CAObGJnNRbA1sKuTCBLpdUtLmjNW+qgRZrGd=dHZ7ZrfXkJJizw@mail.gmail.com> <5426682C-48CB-4D7D-A9DF-01FB17B168E8@island-resort.com> <9EDE7661-4443-4D2E-BF72-FBF238A6EF4D@intel.com> <CABF0A5F-DC51-4D38-8772-6351FA80E6A8@island-resort.com> <A998AEAF-3E1C-480A-866D-410D0B0D4362@intel.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-CMAE-Envelope: MS4xfM2Oo2LZUJhBKmdQsiWyYCw2L2Zlz+VazwVHnWk/2wkppecOK0EFieEGvMzrMOYuJV1u+nceI6fzbd7YondDXB7XUQzrAtBLpw3Hp9cnAOkangPqCr71 eila6ZrNoPUp59T3ojXg3PeC3aq7Lp8PT17YCAG4HUzduv2dgbg97d35OAe3dg3BzXZ+Rho9MKeysop6ASkG6oZmLrq5LFbpyht/4P/qh1v7DSHi15FeGaMt eTaOCcRmTxE3VOn0q7DVHg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/tVbuxoueae0LbtHCFu_fN8m5f8U>
Subject: Re: [Rats] Definition of an Attesting Environment (and layered attestation)
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: Wed, 14 Jul 2021 04:56:11 -0000

Thanks for the comments, Ned. Helps close the loop.

> On Jul 13, 2021, at 4:14 PM, Smith, Ned <ned.smith@intel.com> wrote:
> 
>>  Attesting Environment don’t ensure integrity
>> There is a sentence in layered attestation that goes “The first Attesting Environment… has to ensure integrity of the boot loader”.
>>  
>> Yes, the “ROM” does need to ensure integrity of the boot loader in this architecture, but I don’t think it's the Attestation Environment that is doing it. It’s another part of the  ROM that’s doing it. I would call that functionality staged boot and don’t think it has much to do with attestation.
>> NMS> The term ‘attesting environment’ is normative while ‘ROM’ is exemplary. The statement above seems to blend terminology between something that might read like normative from exemplary text. E.g., ‘attesting environments’ seems more normative language while ‘the boot loader’ seems more exemplary. Given the goal wasn’t to write a normative definition of layered device it seems to live up to its expectation. Does the WG want to see normative definition of common device patterns like layered device and composite device?
>  
> The statement that the normatively defined “Attesting Environment” “has to ensure the integrity of the boot loader” is the biggest point of confusion in all this for me. Personally I don’t think it is correct.
> NMS>  I think the text “the read-only BIOS in this example,  has to ensure the integrity of the bootloader” is wrong since the example no longer has a “read-only BIOS” component. It should say “ROM” to be consistent. If ROM is changed to RoT then it would be changed along with all other occurances.


The thing that resolves this sentence "The first Attesting Environment… has to ensure integrity of the boot loader” is making explicit that the first execution environment (the ROM/BIOS/…) has two jobs:
   - Securely start up the following environment, the boot loader (which it can do in many different ways)
   - Host the Attesting Environment that measures the following environment, the boot loader

It would help me (and maybe others) understand layered attestation if the text made this clear.

With the sentence as is, I wondered if there was a RATS Verifier on the device or not. The definition of Attesting Environment is something that produces Evidence and Evidence has to be checked by a Verifier… so maybe the intention is that there is a Verifier and that is the means by which the integrity is ensured. It is through this email thread that I am clear that is not the intent.

LL