Minutes interim-2022-rats-01: Wed 10:00
minutes-interim-2022-rats-01-202201261000-00

Virtual Interim meeting RATS/TEEP/SUIT

Wednesday January 26, 1800UTC
webex:

Slides are at:
*
https://datatracker.ietf.org/meeting/interim-2022-rats-01/materials/slides-interim-2022-rats-01-sessa-teep-requirements-relevant-to-class-id-discussion-00

Present:
 1.     Ira McDonald
 2.     Laurence Lundblade
 3.     Nancy Cam-Winget
 4.     Ned Smith
 5.     Roman Danyliw
 6.     Russ Housley
 7.     Hannes Tschofening
 8.     Henk Birkholz
 9.     Scott Fluhrer
10.     David Waltermire
11.     Dick Wilkins
12.     Michael Richardson
13.     Dave Thaler
14.     Brendan Moran
15.     Kathleen Moriarty
16.     Guy Fedorkow

Notes taken by Michael Richardson, Nancy Cam-Winget, and Russ Housley

Note Well presented

Dave Thaler talking about slides. Presenting TEEP use cases that describe
requirements for SUIT and RATs.

MCR asked if a Venn diagram has been attempted.
DT suggested that requirement 1 and 2 might be satisfied by a single claim
registry, but that hardware might have multiple claims associated with them,
but was uncertain if that translated to a single claim in the Evidence.

BR: we just need to know if it is compatible, so any identifier works, as long
as it matches and does not overlap.

MCR departs meeting here. (13:28)

DT: mentions that there are 2 related topics: what goes into a SUIT manifest
(that the attester uses to evaluate its relevance), the second pieces is the
evaluation of the actual attestation values.  The purpose of this meeting is to
determine what should go into the SUIT manifest but can also have discussion of
the interdependencies. Describes the TEEP use case and its need to determine
what the SUIT manifest should contain.

BM: aligns in general...attestation evidence doesn't need to have information
about the taxonomy to reduce bandwidth, especially for small devices.  Don't
send redundant information.

DT: what would verifier use?

BM: identifiers need to indicate many different things, and it could be a list
of identifiers, or single that names the whole bundle.  Can we support both
approaches?

DT: there are large devices that Intel is generating vs. IoT (constrained
devices)

BM: we should not preclude either case

DT: a specific device might be designed to implement a particular
specification, but it will just identify the device model

BM: understands Dave's point, attestation results do need more detail as the
verifier will need that information; but sees that we should not require it i
the evidence

DT: any claim you put in attestation result, there may be a manufacturer that
may want to put it as evidence

HB: the claims cannot be globally understood

DT: it's a policy decision

HB: but it could be overloaded in a signature

DT: from TEEP perspective, it doesn't care what's in the evidence as it never
sees evidence.  It cares about what is in the attestation result.

NS: Does the attestation ??

DT: reiterates TEEP only cares about what's in the attestation result as the
evidence is passed as an opaque result

Brendan presents.  Created slides with Henk, to discuss what is in the SUIT
report draft and the SUIT EAT claims (in RATs).  Describes the relationship
between the drafts.  There may be overlap in the parameters for the SUIT
components that is also defined in the SUIT EAT claims; proposes convergence to
a component that is referenced in the SUIT reports draft by defining one EAT
claim that gets defined in the SUIT RATs claims draft.

RH: trying to understand recommendation

BM: clarifies the converged proposal

DT: not sure he understands proposal

BM: SUIT EAT claims draft has every SUIT parameter as a claim, but that needs
to be reworked.  But those identifiers are already defined in SUIT manifest
draft; doing the translation to a claim seems a lot of extra work that may not
be necessary.  The SUIT report has a way to help as it has a container
definition that can be used as the EAT claim

DT: (he speaks too fast!)  Seems some claims seem to be in duplication

HB: existing definition of the system and SUIT claims should be semantically
equivalent to what is being defined in RATs

DT: presented a table that showed claims that are already represented in the
EAT draft.

BM: it's legitimate to have in SUIT multiple class and vendor claims (even
encouraged), but not sure how that maps in RATs

DT: asks to clarify are you trying to identify vendor or class?  Are they in
the same claim set or they are atomic within a claim set but can have multiple
claims

BM: both

DT: elaborates on use case

BM: can have a single component that matches different classes. Describes
example for running checks of bootloader vs. hardware.

DT: within each claim set, each would be a singleton claim.  Class identifier
can see that one as being interesting and maybe seeing it in multiple claim
sets vs. multiple values

LL: discussion is more about software compatibility.  If there are clear claims
that we have agreement and are broad for software updates, they can be included
in the EAT document.  But it seems that it is more SUIT specific vs. EAT
claims.  Preference is that it is not in the EAT document and not hold the EAT
draft.

BM: agrees and is suggesting that the document gets moved out of RATs and go
into SUIT

HB: can use the definitions used in SUIT, but the equivalences need to be
clarified and explicitly spelled out which can be done in SUIT

LL: just wants to ensure that we don't duplicate

HB: device, vendor and version are the three that overlap

LL: the claims iof interest are UUID, hardware vendor/OEM, hardware model and
hardware version those are the relevant claims he sees as needing discussion. 
Vendor not attestor.

NS: that is the discussion that we should focus on, question is where should
that discussion happen (RATs or SUIT)?

LL: if it's a claim then RATs; both in its semantic meaning and how it is used

RH: that makes sense, but from SUIT charter, one of the points of description
for firmware status should be done in SUIT independent of whether it uses EAT

DT: that's what his presentation was trying to highlight, given the overlap.
SUIT can define how the claims are used

NS: does any of this tie into which drafts need to be adopted?

DT: Laurences has already specified that EAT spec already has the claims that
should map to SUIT

HB: Can Dave T. reiterate the mapping on the list to continue on the list.

NCW: suggests the discussion be continued at least with SUIT and RATs and
perhaps include TEEP

NS: RATS and SUIT have respective drafts that should be aligned. The
discussions should happen in both WGs simultaneously until alignment is
achieved. TEEP can be informed of alignment status as needed. Calls for
adoption may be premature until there is rough consensus on alignment between
affected drafts.

HB: believes there should be a merge where they end up is another further
discussion

Ned calls time and ends session