Re: [Teep] BoF call Mar 15th 7am PST (3pm CET, 10pm CST)

[Mingliang Pei <[e-mail]>]

Hi Dave,

Thank you very much for your clarification. It is great to have your precise elaboration :) I see the subtle difference you meant here. The root of trust should be detached from secure boot, allowing certain flexibility for different TEE models. We should and will consider this good point in the spec update. Thank you again for helping on the view point.

Ming

From: TEEP <[e-mail]<mailto:[e-mail]>> on behalf of "Wheeler, David M" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 15, 2017 at 12:14 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teep] BoF call Mar 15th 7am PST (3pm CET, 10pm CST)

Mingliang,
Thanks for taking the notes. It is so hard to do so while also participating in the conversation.
I have a correction to the minutes for the statement:
> Dave from Intel indicated that SGX won’t have a root of trust at firmware level. Current OTrP > > assumes a trust from firmware to above. We will need to adjust on this as part of the IETF work.

Apologies for not being clear. SGX does in fact have attestation root in the Silicon/Hardware. At some level one would attest to the microcode on the CPU.
However, the OTrP specification ties attestation to the Secure Boot firmware of the device. This is very specific, and very different from SGX (and other TEEs).

See definition “Secure Boot Module” (SBM) page 7, section 3.1

In TrustZone, it is important that the boot of the device be trusted so that the security monitor and (if there is one) the RTOS in the security world, is trusted. This trust is established during boot of the device, and such trust in the TEE is inextricably linked to the boot of the device. This is perfectly fine. Intel has some hypervisor TEEs that work in exactly the same way.

However, this is not the only way a TEE can be established, and there are different trusted execution environments that are not burdened with trust linked to the boot of the device. The definition of trusted firmware and the root of trust being linked to the secure boot of the device is implementation-specific, and should be changed. We need a broader definition of root-of-trust.

Thanks for allowing me to better explain my position.

Dave Wheeler

From: TEEP [mailto:[e-mail]] On Behalf Of Mingliang Pei
Sent: Wednesday, March 15, 2017 9:44 AM
To: Nancy Cam-Winget (ncamwing) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [Teep] BoF call Mar 15th 7am PST (3pm CET, 10pm CST)

Meeting minutes for today’s call. Please correct or update if I have missed some major points. Thanks, Ming

————

TEEP meeting
03/14/2017

Participants: Nancy Cam-Winget, Kathleen Moriarty, Brian Witten, Dave Wheeler, Nick Cook, Mingliang Pei, Rashid Sangi, Tero Kivinen, Jeremy O’Donoghue, Tirumaleswar Reddy, Dapeng Liu, Michael Richardson

Nancy hosted the meeting. Ming started to give a summary of use cases and comments by Michael in the mailing list.

Michael clarified that he wants to know why a smart door lock needs this where only a trusted environment is there. We (Brian, Hannes, Ming etc.) discussed that there are still needs to define trust where application injects TA from insecure side, being network, remote, or update.

The discussion indicates that we need to better see what the problem the charter tries to solve, who are stakeholders etc.

Dave suggested that we don’t put use cases too close to implementation. Some resource constraint devices don’t have full TEE.

Jeremy noted that some audiences don’t all know TEE. Hannes will introduce TEE in the BoF. To this note, Hannes prefers someone from Intel to introduce Intel SGX.

Nancy summarized two asks so far: introduction of TEE to set stage, and secondly show why the work needs to be done in IETF.

Nancy raised a personal view that we shouldn’t prescribe hardware architecture, and even there must be a hardware required to isolate. Some research has been using SW for isolation. People agree that this should be independent of hardware, ARM or Intel (SGX). On the requirement of hardware, this is generally considered yet – some isolation done by hardware and scope of assumption. We don’t want to get into a research project for the IETF work.

Dave from Intel indicated that SGX won’t have a root of trust at firmware level. Current OTrP assumes a trust from firmware to above. We will need to adjust on this as part of the IETF work.

Ming noted that we should work to define the scope of the spec this charter tries to address. We cannot leave it too open to solve everything. The current assumption of TEE presence is one. The assumption of hardware presence is one. Multiple different TEEs support and hardware independence are basic in scope assumption etc.

Jeremy raised a need to ensure specific interests should be guarded away from this work, and some kind of gate keeper (?). Brian commented to fully concur, and our work wants multiple TEEs, CAs etc. for competition and development. This doesn’t fully address Jeremy’s question, and we can think more.

Nick suggested that we also name sample applications that may make use the work while describing use cases.

To summarize, we came away with the following several planning work for BoF session candidates:


-        Clarify charter statement during BoF. From the call, not all people agree or have the same background with TEE, SGX and so on.

-        Introduction of TEE (Hannes, Dave on Intel SGX). A colleague of Dave will be attending BoF. Dave may join remotely.

-        Drive to define problem scope.

-        Discuss use cases that are in scope and those may be not

o   Discuss applications that may make use of the work of this charter, which can provide more concrete context.

-        Discuss stakeholders and protocol architecture

Action items:

-        Dave Wheeler from Intel provides SGX introduction slide, and prepare to present at BoF by his colleague, and him remotely

-        Discuss in mailing list to clarify charter and problem domain scope, use cases.

-        Discuss offline to clarify concerns Jeremy raised for openness / gate keepers (?)


From: TEEP <[e-mail]<mailto:[e-mail]>> on behalf of "Nancy Cam-Winget (ncamwing)" <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, March 15, 2017 at 7:08 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Teep] BoF call Mar 15th 7am PST (3pm CET, 10pm CST)

All,

We are about to start the BoF now….please join the webex if you want to participate.

Thanks!  Nancy

From: TEEP <[e-mail]<mailto:[e-mail]>> on behalf of "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Date: Saturday, March 11, 2017 at 5:10 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [Teep] BoF call Mar 15th 7am PST (3pm CET, 10pm CST)

All,
We had a good majority for Mar 15th 7am PST (3pm CET, 10pm CST);  I’ve setup a webex for that time slot
Please see info below.

Please send us agenda items for the upcoming call.

Thanks, Nancy



JOIN WEBEX MEETING
https://cisco.webex.com/ciscosales/j.php?MTID=me9216d73c5905ad78110499a8c7c12bf
Meeting number (access code): 207 779 570
Meeting password: KEQ52p3W (53752739 from phones)



JOIN FROM A VIDEO SYSTEM OR APPLICATION
Dial sip:[e-mail]<mailto:[e-mail]>
>From the Cisco internal network, dial *267* and the 9-digit meeting number.  If you are the host, enter your PIN when prompted.


JOIN BY PHONE
[phone] Call-in toll number (US/Canada)
[phone] Call-in toll-free number (US/Canada)

Global call-in numbers:
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=379001592&tollFree=1

Toll-free dialing restrictions:
https://www.webex.com/pdf/tollfree_restrictions.pdf



Can't join the meeting?
https://help.webex.com/docs/DOC-5412


IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session.