Re: [Rats] EAT claims needed by TEEP

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 09 November 2021 13:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 B74EF3A0CC3; Tue, 9 Nov 2021 05:40:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZMe_yNXLKd8Y; Tue, 9 Nov 2021 05:40:05 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB7663A0CBC; Tue, 9 Nov 2021 05:40:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3EE261803C; Tue, 9 Nov 2021 08:41:56 -0500 (EST)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qf9x9CXsx2cO; Tue, 9 Nov 2021 08:41:53 -0500 (EST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 95E9C1807B; Tue, 9 Nov 2021 08:41:48 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6079085F; Tue, 9 Nov 2021 08:39:53 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "rats\@ietf.org" <rats@ietf.org>, teep <teep@ietf.org>
In-Reply-To: <CH2PR21MB146427B07435A5F36DAE5782A3919@CH2PR21MB1464.namprd21.prod.outlook.com>
References: <BL0PR2101MB102770B8E03B95A44497004CA3190@BL0PR2101MB1027.namprd21.prod.outlook.com> <7607E6BF-459C-4A32-AAE2-08117A97E06B@island-resort.com> <BL0PR2101MB1027EA205417DAF375BA7085A3160@BL0PR2101MB1027.namprd21.prod.outlook.com> <B1FDD70B-2530-454C-90AF-F44EEDC4F1F3@island-resort.com> <AM6PR08MB342916CCDD01E8698BB3C883EF170@AM6PR08MB3429.eurprd08.prod.outlook.com> <2D53BD60-4FA8-4153-B28B-585E902845AE@island-resort.com> <AM6PR08MB423141370A5CE9DEF6C732C69C140@AM6PR08MB4231.eurprd08.prod.outlook.com> <3370D92E-23C2-41C3-B86F-A65C168E9082@island-resort.com> <AM6PR08MB42311D76B24E866812171BDC9C140@AM6PR08MB4231.eurprd08.prod.outlook.com> <CH2PR21MB14640330E3DA58D2144659F7A3919@CH2PR21MB1464.namprd21.prod.outlook.com> <C9FCDB94-1734-4F6C-B6D9-DDB384827E06@island-resort.com> <CH2PR21MB146427B07435A5F36DAE5782A3919@CH2PR21MB1464.namprd21.prod.outlook.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 09 Nov 2021 08:39:53 -0500
Message-ID: <27150.1636465193@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/bvEfcqfUkVRnjaZTmDQwwl2AV68>
Subject: Re: [Rats] EAT claims needed by TEEP
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: Tue, 09 Nov 2021 13:40:11 -0000

I'm reviewing the pull request at:
   https://github.com/ietf-rats-wg/eat/pull/139/files

About the hardware-class-claim.

  "There is no global scheme or format for this claim."

So I wonder how TEEP's flow will deal with this.
Forgive me if that's buried in TEEP somewhere.
If so, I think that the EAT document should perhaps refer to that informatively.

I can see how the verifier can be okay with lack of scheme: the signing key on the
evidence can index into a database of devices, and then it's a string
comparison to see if the device claimed correctly.

But, equally well, the verifier already knows, via that database, what the
value is.  The only utility I can see if that the RP is going to see this in
the Attestation Results and use it to decide what binary to ask the TAM to
load.

I'm concerned that any hardware vendor can put any value in this.
The Verifier, provided by the hardware OEM, agrees.
The only thing the RP can do is the rely on it's contract with the Verifier.
That's actually the thing the RP ever does, I think: so don't mistake me.
What I'm asking is, given that, is this claim even needed as evidence?
Maybe it's only useful as Attestation Results.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide