Minutes IETF112: teep
minutes-112-teep-00

TEEP IETF 112
November 12, 2021 Session I

Chairs: Nancy Cam-Winget, Tiru Reddy

Notetakers: Hannes Tschofenig, Tiru Reddy

Agenda bashing, Logistics – Chairs (5 mins)
Nancy went through the chair slides.

Hackathon Report & SUIT Manifest for TEEP discussion – Akira Tsukamoto(15 min)
Akira talked about the TEEP hackathon experience. Akira & group filed several
Github issues.

Dave mentioned that the PR 161 was not merged into the draft due to conflicts.
Regarding the topic of where the examples should go: It depends whether they
are more generic or TEEP specific.

Henk: There are also merits to put the examples into a separate draft. SUIT is
happy to help.

Akira: I only have concerns to have the examples in the SUIT manifest draft
because it is TEEP use case specific.

Brendan: With the refactoring in SUIT, there are now multiple document, I
believe it would be better to have TEEP examples in the TEEP document.
Currently, not even all SUIT examples are in the SUIT manifest draft because
the contet was distributed over several documents.

Henk: Could you repeat?

Brendan: If TEEP is a profile of SUIT, then it should have its own exampes in
TEEP.

Henk: Would it be its own doument?

Dave Thaler: question is whether they are actually TEEP specific in terms of
the main points. I have no real preference myself.

Ben: The main thing I see as a potential source of issues is is we have a lot
of examples (like maybe 20+ pages) that we want all in one place. We might get
pressure to make a dedicated “examples” document and not have that much in the
actual protocol spec. Other than that, I think we can decide where we want the
examples and then finesse the surrounding text and references to make things
work.

Dave Thaler: so question is about TEEP WG or SUIT WG (in some doc with examples
of doing various things like embedded payload, referencing binary by URI, etc)

Nancy: We are probably not going to get a resolution on this topic in the
meeting.

Dave Thaler: It would be good to go through the examples and make a judgment
whether they are SUIT generic or TEE specific.

TEEP Protocol – Dave Thaler (80 mins)
Dave went through the open issues.

Issue #83 - Token

Russ: The tokens need to be different per request. I hope that implementations
do not keep history of all transmitted tokens.

Dave Thaler: There are ways not to keep state.

Russ: There is some wordsmithing needed to explain what the uniqueness
requirement is.

Issue - EAT

Dave shows a mapping to TEEP requirements and their corresponding claims in EAT.

Brendan believes we need to carefully check the relationship between SUIT, TEEP
and RATS. I believe the device identifiers are the claims TEEP will care least
about.

What is the Class ID? What are the uniqueness characteristics?

Brendan: It allows someone to distinugish different configurations, such as a
TEE with a specific trusted peripheral. There are a lot of different options.
There are different use cases and therefore lots of ways a class id can be
utilized and structured.

<Missed> discussion between Brendan, Henk and Dave Thaler</Missed>

Is it TEEP specific?
Is the value globally unique?
It is opaque or structured?
What should be the data type? String, UUID, etc.

Eric argues that it is globally unique (but vendor extensibly). It should be a
string.

Hannes asked DaveT. for a summary.
Dave responded that he cannot provide a summary.

Henk (What should be the data type?): Not sure if usful for TEEP, but in RATS
endoresments hw instance/class/group identifiers are complex trees with various
types of identifier semantics ranging from oid to signed integers

He summarized the comment from Brendan by saying that there might be multiple
class identifiers.

Brendan clarifies:

General problem (since the topic is also brought up in RATS and SUIT)
class id should be scoped by vendor or profile; they are not globally unique.
Security features are always tied to profiles or vendors. it must be opaque
make it a UUID since you can make everything a UUID type5 (which guarantees
that it is opaque) Dave liked the summary from Brendan and agrees with it.

Henk agrees with Brendan as the claim would only cover evidence and not the
complexity of endorsments.

Ira McDonald: +1 to Brendan’s rationale for UUID only - because it’s reliably
opaque

Poll:

EAT should do claim, but leave values to be defined by vendors and profile =>
strong consensus Value should be opaque => strong consensus Issue - EAT profile

Q: documented in TEEP document or separate spec

Dave Thaler – proposal: put it into the TEEP spec
Ira McDonald: Agree - put EAT profile into same spec
Daniel Migault: +1 to Ira

Issue - SUIT

Q: Removing (unlinking) a component

The default answer is option 1.

Brendan: How do you get the privilege the unlink (if you not the signing
author)? This looks like what an attacker may want.

DaveT: Option 2.2 is not out of question.

DaveT: Do you have to remember who installed it to uninstall a component? If
any trust anchor in the TA store is equally trusted.

Brendan : Any equally trusted TA should be allowed to do so?

Brendan: Are we unlinking components or manifests?
Where do the links come in the first place? If it has not been installed
manually, then how do you unlink it. You can only unlink a componet that has
previously been installed. If you have locally installed a component then you
should be allowed to unlink it locally. I believe you have an uninstall command
sequence?

DaveT: This would go into the trust domains document.

DaveT: TEEP should go forward with option 1 but SUIT should explore option 2.2.

Brendan: The notion of uninstalling needs some exploration because it wasn’t an
issue in the SUIT area.

DaveT: Clarifying text that focuses on option 1. Unlink manifest has the
largest sequence number.

Ira: Are you trying to uninstall a component or a manifest?

DaveT: Brendan believes either one is OK.

Issue - Personalization

No questions.

Issue - Ciphersuites

Simplifying ciphersuites and use only one registry (from COSE). No objections

SUIT meeting decided that HSS-LMS is a MUST implement.

Issue - Overwriting TC binary URI

Brendan:

Other options: Caching. There is nothing from stopping you from caching it in
your local network (assuming the HTTP request). Use of integrated payloads:
download the binary upfront and use the uri in the envelope. This would be a
transparent cache. Device-local HTTP cache may be appropriate as well. DaveT:
It would be good to describe this on the list.

Issue - Unsolicited QueryResponse

Proposal to allow TEEP Agent to send unsolicited QueryResponse under certain
conditions.

DaveT: Objections?

No objections

Next steps

Early review, implemenation work, and WGLC around IETF#113

Summary Notes:

1. Nancy presented the chair slides.
2. Akira presented the TEEP hackathon report and the several issues filed in
Github.
    a. Discussion on whether examples should go in the SUIT manifest draft or
    in a TEEP document. It will be decided after re-looking into the examples
    if it is SUIT generic or TEEP specific.
3. Dave presented the TEEP protocol draft and went through various open issues.
 a. The tokens need to be different per request. Implementations do not need to
 keep history of all transmitted tokens, Dave will update the protocol draft
 for better clarity. b. Discussion on class identifiers whether it is TEEP
 specific or general. Whether it is globally unique or vendor-specific.
 Multiple types of class identifiers are possible, complex hierarchy trees. The
 path of least resistance is to make it specific to TEEP profile, vendor
 extensible space and TEEP protocol will define new claim and IANA registry. c.
 Strong consensus for EAT should do the claim, but leave values to be defined
 by vendors and profile. d. Strong consensus in the WG that the class
 identifier value must be opaque. f. UUID can be used to keep the class
 identifier value opaque and it will be discussed in RATS WG. g. Consensus to
 keep EAT profile in the TEEP protocol document. h. SUIT related issues (a)
 Removing (unlinking) a component, option 1 in the slides is preferred. Option
 2.2 will be discussed in SUIT WG. (b) No comments on the Personalization data
 scenarios slide (c) Use the registry from COSE for the ciphersuites in TEEP
 (d)  Overwriting TC binary URI, proposal to use caching on the device; it will
 be discussed in the list. i. No objections to Unsolicited QueryResponse.
4. Early review of TEEP protocol draft by iotdir and if all the issues are
resolved, WGLC of TEEP protocol specification before IETF-113