Minutes IETF101: teep
minutes-101-teep-00

Trusted Execution Environment Provisioning

Tuesday 13:30-15:30 Tuesday Session I
March 20, 2018 - London

Note takers: Chris Inacio
Jabber: Pete Resnick

Agenda bashed
-------------
Milestone review: updating website to reflect realistic dates

ask: date for WGLC for architecutre Dec?
Target April 2018 for WG acceptance of arch document
Dec 2018 nominally accepted as a strawman (primary authors nodding acceptance)
Mar - July 2019 to progress to IESG

----
WG Overview Presentation (chairs):
https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-problem-statement-recap-00

----
TEEP Use Cases:
https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-potential-use-cases-00

Wheeler  Are we missing TAM for APP validation?
David/Chair: No, those are different functions of roles
Wheeler: Thought TAM was independent
David/Char: No, but they could be (function of 2 of the current roles)

Any uses cases to rule out / or all these valid?

Subir Das:  which TA should be out of scope, but does that mean that 2a is out
of scope

<some discussion lost due to Etherpad going down>

hannes: good idea to recast use cases into those different roles
    we don't want to constrain on who runs the TA, thinks that is the right
    approach

Mingliang: role, chip vendor, doesn't need to be in scope

Subir Das:  good to be add TAM to the entities list
chair: can you think of a case where it isn't one of the already existing 5
subir: yes, when it's a 3rd party
chair: please write up a use case for that
subir: yes, I have see it that way, will write it up
wheeler: +1 / YES

Gene Golovinsky: (missed comment) :(

hannes: Subir has a point, the secure OS vendor also provides TAM, but it could
also be a 3rd party chair: do you have a term (managed security provider) but a
better term would be accepted

mingliang: enterprise may have a 3rd party TAM provider; outsource their TAM
functions to their security provider entity

==========

Arch: Hannes
https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-architecture-00

chair: security session follows red lines in the arch diagram - focus of the
group

subir: I do support that 1 TEE requirement
subir: Is there another way to reach a TEE without using an app and/or agent?
subir: Does device OEM have another way to talk to TEE
mingliang: for normal app, you need shim to make the TEE to create the API
hannes: need soemthing like a kernel module that talks to the network & talks
to the TEE hannes: those two could be merged together (agent & app); not
excluding that, but 2 different roles (talking outside the box & talking to TEE)

wheeler: mic isn't working (waaaa, waaaa, waaa)

dave thaler: doesn't know why we need to have a concept of "device", just need
the concept of a TEE

wheeler: there must be multiple TEE's though
wheeler: device is the relationship between OEM and TEE

sven schrencker: must allow to have multiple TEE's; already have those

mingliang pei: we started with 1 TEE, looking at phones for example, you can
have multiple TEE's as long as it doesn't matter which TEE you talk to

max pritkin: relathionship between TEE doesn't matter, but then how do you
install the agent / app; at a minimum you need to say the device exists to
state that the device doesn't necessarily know what is installed in the TEE

chair: no support for not having device and support for having multiple TEE's

chair: define what you mean by security domain / provision data area, app, etc.?

hannes: struggling with this, comes from the smartcard world, but that has
changed hannes: its a data container / multiple apps can access data in TEE

mingliang: I agree.  conceptually its isolation

thaler: refinement of the use case statements.  this defines the isolation view

arashmid akhavain: each slice in the security domain can present a different
set of

andrew atyeo: security domain - just a relationship with the service provider
outside the TEE; not clear there is any data sharing mechanism in place in
which multiple trusted apps can share data

eric nordmark: many to many relationship between apps and the isolation domains
seems like it would be hard to get correct and who would manage that? hannes:
discussion on mailing list about 1:1 vs n:m;  eric you say 1:1 eric: (nod yes)

mingliang: ????

thaler: even if the thing is 1:1, you can still have multiple things talk to
that; but do you want that complexity eric: if I have someone who manages those
policies, who's going to manage that, refering to app B vs. B', especially
complicated when its many:many
    need to understand that use case before you design that
mingliang: the intel can run a big app, including an OS
eric: an app is 10K vs 10M, what is the scale of an app
sven schrencker: the enclave is defined, so it can be arbitrary, so it can be
very large wheeler: not an ability to run an OS inside SGX

Protocol / Solution Document (mingliang) :
https://datatracker.ietf.org/meeting/101/materials/slides-101-teep-open-trust-protocol-01
========================================

chair: currently presenting just what's being done today.  Not necessarily
what's the goal of the WG

max pritkin: confused about use of TASM & TAM
chair/mingliang: TSM and TAM are synonyms.  TSM is the older term changed to
TAM.

Arch Questions (chairs)
=================================

1/n message formats??
should cbor be supported:

hannes: json was selected originally because envisioned for mobile phone app
developers, original use case environment hannes: then people brought up IoT
use cases, but that's more tricky, should CBOR then be supported, not sure
hannes: CBOR generally would include COSE, which might include some more
significant changes chair: not a right answer now, need to define this now, and
then do the right work from that hannes: also stated want to have alignment
with SUIT WG, they selected CBOR/COSE SUIT chair: assumption in SUIT that you
will have a CBOR parser but not necessarily a JSON parser

jeremey: as currently defined JSON may not be transformable to CBOR
chairs: believe it is convertible, but will check
dave crocker: multiple formats breeds complexity and errors, what's the reason?
chairs: reasons are stated, might need support for SUIT
wheeler: CBOR to support IoT
crocker: might be good to express that there is 1 format, with multiple
serializations

brett jordan: generally against multiple forms of serialization, pick 1, it
increases implementation cost

chair: from the list:  both protocols mandatory to implement at the TAM, but
agent only has to speak 1 chair: continue conversation on the list

crocker: thales interpretation of his statement is different; single common
format, but separate effort for a gateway

henk b. : tcg starts using cbor

chair: should TEEP consider multiple transports?  HTTPS / CoAP / ???

andrew atyeo: need to specify more than just which protocol, what's inside

chunshan xiong : which version of the various protocols.

mingliang: currently uses 1.1 in the global platform

hannes: COAP can't use on its own, or COAP over TCP.  differences in
performance in the various versions

max pritkin: why just talking about HTTP when we should look at a whole stack,
e.g. COAP & JSON doesn't make sense

hannes: haven't seen newer version of http used in IoT environment

chair: heard multiple or COAP, but haven't heard HTTPS only

mingliang: IoT use is different then richer device;  on device pick 1, but at
TAM can support more

Sorin Faibish: be sure that you can represent the interest in IoT; other
devices can support the IoT case

henk b: +1 to max for COAP & CBOR;  COAP over reliable should be discussed more

chairs: how many have read the draft?
chairs: should the WG adopt the draft as the WG draft

david kemp: question phrase: about supporting creating an info model and
sharing with SUIT

chair: draft contains an entire flow for the protocol
chair: should we start from this draft

waldermire: should defer on the data model for now anyway

bret jordan: second what dave w. said

<hum to adopt>: consensus to adopt

wheeler: okay with this as a starting point, but larger issues need to be
addressed jeremy o'donoghue: starting with draft 6 will ease compatibility with
global whatever

Meeting dismissed.