Re: [Rats] EAT claims needed by TEEP

Thomas Fossati <tho.ietf@gmail.com> Thu, 11 November 2021 10:34 UTC

Return-Path: <tho.ietf@gmail.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 B6C9C3A0C80; Thu, 11 Nov 2021 02:34:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fmIKaLh3ssuj; Thu, 11 Nov 2021 02:34:53 -0800 (PST)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E8773A0C7B; Thu, 11 Nov 2021 02:34:52 -0800 (PST)
Received: by mail-lj1-x22e.google.com with SMTP id e11so10941603ljo.13; Thu, 11 Nov 2021 02:34:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=iK6CdKi0r5V1NdJHleE9Tz1Vcg4muawytGxynf5+svs=; b=colzOplnUJIbijAy+IWwjua8R6MWxAJgMS2LRoYx71x3BkIu4BBTfy7zzXr4tqBk5r GfeKvU2Kd0usDoUDGIuaWZYd1V1+OVMT1qR4Je3s4D1bBfaebJYOQmqykg8Y/ZsoEpH7 i/VpKIyHBguL0Qka1kevQm39JmQw9BqFkJKXahJ1guHj6qYuK8ef7ji4RhHxLbrjozJF Bd3991EmugUEOdFOHTKL6VcB7o6t3L4Ww7XDSX3NjShM1+EIzp6lpuiZKy78AlMRD9v+ /6PUhCO2tnwnNnZTY5+84XEj8OQLAdcelXQ/vnK47Qyt95z4nNZGr6NC7Nfn347tHk9t XGOw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=iK6CdKi0r5V1NdJHleE9Tz1Vcg4muawytGxynf5+svs=; b=uScDdDEcbsKsoSCh+3XnQuFqY/TRG79BU0ModuRQeWmUU5jgL9y/AEix5UuAhOlP2R EJK6Gab6aIj11sY31MoyyT5lAoJB/j5V2ekD1XL//c1RkfpyRLZ8TCZuaFUnrQulP7Oa LfC/vKYpBrTFUlRK0NFG1hUfPiyp9LqbWrFyBU/K1/KrmybueyTO/0hg3/6wP+0t2AZM PVu0/xkkTW7wLeg8VbLEVKFEQdbdFoerCgB2tbFqarO3Hc44IiriIhFBcySJuCLJbpvz Gh/BgTbNH0IaUOoo01qZy7bJ+L0ipJTRkZQX4TKb7dakBt7E65BrcIYbqlAtDbCTfoyO MuJw==
X-Gm-Message-State: AOAM533X0FgLvJSP/n4WvBqTkjTFe3yfKofbXONZN7TuWYXDa6HnVN4S KB41HhJFLi8ZfYeA4qqVJGMWBvxEoW2TNYZwUXvIVHqzb3Y=
X-Google-Smtp-Source: ABdhPJxJmdG9nRS3Qts0InrvnXn5ZwfQayUCAhK6l6NDrJhQKxBWk4uS5G+x3Rax/lVRWKM/jJ8MyHyEpdDrFbcoZLs=
X-Received: by 2002:a2e:b053:: with SMTP id d19mr5909848ljl.231.1636626889937; Thu, 11 Nov 2021 02:34:49 -0800 (PST)
MIME-Version: 1.0
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> <27150.1636465193@localhost> <A40BE985-E12E-4B5E-8995-F4408134AEE4@island-resort.com> <398725.1636575788@dooku> <CH2PR21MB14646282D207490FD0C6D69BA3939@CH2PR21MB1464.namprd21.prod.outlook.com> <43D84D56-26B1-4726-A3AC-E918071592BB@island-resort.com> <CH2PR21MB1464E91FD236666F94C3A380A3939@CH2PR21MB1464.namprd21.prod.outlook.com>
In-Reply-To: <CH2PR21MB1464E91FD236666F94C3A380A3939@CH2PR21MB1464.namprd21.prod.outlook.com>
From: Thomas Fossati <tho.ietf@gmail.com>
Date: Thu, 11 Nov 2021 10:34:39 +0000
Message-ID: <CAObGJnMh0+GFySpovD-YoSF34o+cMEj-h+NSMUoEiBHT8WadWQ@mail.gmail.com>
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
Cc: Laurence Lundblade <lgl@island-resort.com>, Michael Richardson <mcr+ietf@sandelman.ca>, teep <teep@ietf.org>, "rats@ietf.org" <rats@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/Zh7IVlOF5fgAXjoTe1YFpZbe1SM>
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: Thu, 11 Nov 2021 10:34:58 -0000

There has been some detailed discussion on the PR [1] but I'd like to
point out a couple of more high level considerations.

Using a byte string (i.e., with no explicit typing) means coupling all
the RATS roles around the *syntax* of the claim.  For example, a
reference value provider (maybe a third party rather than the ODM
itself) would need to have detailed knowledge of the specific encoding
used by the attester on a given device in order to correctly instruct
the verifier.  While this is likely OK for a bunch of very simple
cases, I don't think it's a viable strategy in general.

An OID could be in dotted-decimal notation or BER-encoded or
RFC9090-encoded, an URI could be a string or a CRI, UUIDs could be in
canonical 8-4-4-4-12 format or binary encoded, etc.  All of those
encodings should be possible as long as it's understood by all the
involved roles that the thing is a URI or whatever.  The roles
distinction in the RATS architecture requires shared semantics, not
shared syntax.  In fact, I don't think we can have fine-grained
appraisal policies without a well defined typing system as the base for
the semantic layer.

Besides, it looks like we'd be creating a bad precedent because then one
could easily argue that *every* claim is possibly just a byte string or,
pushing this line of reasoning just a bit further, the whole claims-set
could be seen as one single gigantic opaque claim.

That said, if TEEP wants to go down this road I think it's fair and
fine, as long as it remains within the TEEP scope (i.e., within the
confines of TEEP's EAT profile) and doesn't claim general applicability.

cheers, thanks!

[1] https://github.com/ietf-rats-wg/eat/pull/139/files

On Wed, Nov 10, 2021 at 10:09 PM Dave Thaler
<dthaler=40microsoft.com@dmarc.ietf.org> wrote:
>
> Good point, I agree.
>
>
>
> Dave
>
>
>
> From: Laurence Lundblade <lgl@island-resort.com>
> Sent: Wednesday, November 10, 2021 1:26 PM
> To: Dave Thaler <dthaler@microsoft.com>
> Cc: Michael Richardson <mcr+ietf@sandelman.ca>ca>; rats@ietf.org; teep <teep@ietf.org>
> Subject: Re: [Rats] EAT claims needed by TEEP
>
>
>
> An advantage of a string over a UUID is that it can be very short if that’s all the OEM needs, “S”, “3, “X” and “Y” in the case of Tesla.
>
>
>
> LL
>
>
>
> On Nov 10, 2021, at 1:03 PM, Dave Thaler <dthaler@microsoft.com> wrote:
>
>
>
> If it's a string, I think it should be up to the vendor specified by the oemid,
> rather than by a vendor-agnostic profile.
> If it's a UUID then that's not needed.
>
> Personally I would argue for treating it as opaque in either case
> and a verifier should only compare it for equality, rather than permitting
> semantic structure in it.   That's because I think some hardware implementation
> may fillvin values that can be used for multiple profiles.
>
> Dave
>
> -----Original Message-----
> From: RATS <rats-bounces@ietf.org> On Behalf Of Michael Richardson
> Sent: Wednesday, November 10, 2021 12:23 PM
> To: Laurence Lundblade <lgl@island-resort.com>om>; rats@ietf.org; teep <teep@ietf.org>
> Subject: Re: [Rats] EAT claims needed by TEEP
>
>
> Laurence Lundblade <lgl@island-resort.com> wrote:
>
> Appreciate the comments.  Think it is important to keep this generic
> since it is going in EAT. TEEP can have specific ways it uses HW class,
> but don't think we should be referencing TEEP in EAT.
>
>
> Then I suggest that:
>
>     "There is no global scheme or format for this claim."
> ->
>     "The format for this scheme will need to be specified within profiles that
>      use it."
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr@sandelman.ca  https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.sandelman.ca%2F&amp;data=04%7C01%7Cdthaler%40microsoft.com%7C47461df1d4ae4c6cc7f208d9a487f27c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637721726675767230%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2BOIH8fZw6zju18DcoR9hQ4HkrtDsMkhTXwQTitkKsSQ%3D&amp;reserved=0        |   ruby on rails    [
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats



-- 
Thomas