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