TEEP Notes
TUESDAY, 19 November 2019 at 1000

Chair: Nancy Cam-Winget
Note Takers: Mike Jenkins 

Announcement of Dave Thaler changing roles from TEEP Co-Chair  to contributor and welcoming Tiru Reddy as the new co-chair.

Akira Tsukamoto presents the Hackathon Report, participants where testing out OTrPv1 with HTTP. But moving forward it will be TEEP with TEEP enabled devices.

Dave Thaler goes thru TEEP Architecture open issues and proposed resolutions (resolutions to be confirmed on list):
• Issue #69: Draft is Informational but normative language is used.  Proposed resolution is to switch to regular English to avoid normative text. Hannes Tschonefig agrees normative may not be appropriate and normative should be in the protocol spec. Dave mentions that normative can be moved to the protocol spec. 
• Issue #53, 54, 55: terminology that can affect scoping.  Terms that can be outside the TEE used different terminology.  Proposed resolution to consistently use “Rich Execution Environment” or “commodity OS” depending on context….refers to now being an editor so can actually merge the pull request.
• Issue #68: definition of TEE, proposed resolution “An environment that provides hardware enforcement that (1) only authorized code can execute within the TEE and (2) data used by that code cannot be read or tampered with code outside the TEE”.  Question on scope based on TEE charter, is there a software TEE?  Charter could imply hardware but is not hard definition.  Hannes mentions raising the issue as we want to be inclusive and important based on attack types that need to be raised; TAs also need to be isolated. Charter definition falls a little short, not look at a single processor but look at the whole system; the virtual/hypervisor is also a form of hardware…but this may be too detailed for the document. Dave asks to clarify whether definition is liked or not. Dave concludes that there should be security consideration vs. clarifying in the section. Laurence asks is this a protocol or architecture? Dave says the former and this is more of an applicability statement and the scope.  Laurence not sure he likes any of the definitions, the protocol really doesn’t depend on the text, so not sure it matters. Dave believes it does matter as protocol depends on architectural elements.  Laurence says it seems too much of characteristics of an implementation. Dave clarifies that its more on the applicability of the deployment.  Ben Kaduk: do you want decision of applicability to the person deploying vs. the implementer?  Hannes: makes sense to provide background and context in the architecture document on the deployment, but at protocol level, it could be running anywhere thus the architecture providing the deployment is needed. No objection to take pull request for issue #71 and welcomes suggested text and will continue to work on text for isolation.  Rich Salz: is authorized code in scope?  Dave: it is defined in the document. Giri Mandyam: how it TA to TA isolation handled in the document?  Not sure this text covers this scenario. Dave: was asking Hannes same question. 
•  Dave now covers issues based on SUIT as text was written before WG decided to depend on SUIT manifests.  Issues #13, 34 and 35 are around this. Pull request is to update based on SUIT and add reference to SUIT manifest. Issues #7 and #62 are based on security domains and expressing them inside a SUIT manifest.

• Issues 58 & 30: "device secure storage" vs TEE:
- Hannes asks whether we bring in root of trust for dev secure storage.  Trust anchor isn't same as root of trust.
- Dave considers storage and root of trust an interesting question
- Hannes comments there needs to be some software to go with the hardware and the key that can't be changed
Giri: is device secure store is a superset or equivalent of the TEE?
Dave: everything in table can be viewed that all of them are part of the secure store
Laurence: "secure" or "trusted" implies something is absolute, so need to clarify "trusted for what", is it immutable? In protocol doc, could clarify "secure store" usage and its consideration
Dave: take the comment as agreement to proposed resolution
Ming: implies hardware and includes some manufacturer key 
Hannes: likes Laurence's comments and proposed path; text was not meant to over constrain so perhaps just provide examples to give guidance to the reader
No objections to current proposal, but some elaboration may be needed

• Issue #32 Trust Anchor update
Ben notes that trust anchor config/update could be (may) be updatable (but configured not to as well)
Consensus to make TA update in scope (though no specific proposal for defining procedure
From SUIT WG chair: please have TEEP provide its requirements list for SUIT thru the SUIT issue tracker. 

• Dependencies and issues based on RATS:  
   Issue #17, 31, 70:  attestation notes to be removed and now will reference RATs
    Laurence and Giri: ask questions on how to interconnect with RATs, response from Dave and Ben is that there'd be a profile specific for TEEP
    
• Issue #70
    - Ben proposes the #2 with elaboration (check recording for his wording); Ming agrees
    - Laurence: not sure he likes any of the options
    -Russ; also questions the pkix centric notion that should be relaxed
    -Hannes: agrees that this section should be revisited. To Ben's point the SHOULD was there in x.509 considerations, but as we look at COSE, need to untangle the attestation work for use of the appropriate keys
    - Dave adds #4 option: move discussion to TEEP spec vs. inclusion in architecture
    
• No issue filed yet, but question: no discussion in TEEP architecture on types of claims to be used (from RATs) does it belong in arch, TEEP protocol or TEEP profile 
    Ben says go to 3rd doc (TEEP profile)
   Consensus to use a diff doc and have the architecture draft loosely state using RATs work for attestation
   
• Issue #11: conceptual APIs - basically editorial
   Chair notes that editorial should just be addressed
   

Wednesday Nov 20, 2019
Note takers: Giri, Max

Chair commenced meeting with intro and Note Well.

Same deck as yesterday.

Chair recapped Tuesday session.  Chair then provided an overview of Wednesday agenda.

Architecture discussion continued

Dave Thaler lead discussion (continued from Tuesday session).

Issues #65, #66:  IoT DDoS issues.  Text on whether TEEP could be used to mitigate Mirai-style DDoS attacks.

Is there a relationship between TEEP protocol and DDoS attacks ? The proposal is that TEEP manages the TEE while there is no direct correlation - protection of REE is not in the scope of TEEP.

Proposal is to close issues.  No objections noted.  Issues will be closed with response in GH.

OTrP/TEEP Protocol

Hannes Tschofenig provided an update on the latest version the OTrP draft.

-00 reflected group decision to use COSE/JOSE for encoding, and leverage EAT for attestation, SUIT for manifest, and follow the TEEP architecture. The choices allows for reducing the need to re-design existing functionalities and re-use of existing code.

-01 added Dave Thaler as editor and fixed editorial bugs.

Discussion of naming it TEEP-P or TEEP: Dave T prefers TEEP

During the hackathon we have different options - a couple of field defined for attestation information and there is a cipher suite negotiation built in - you can express that as well. Since we support CBOR and JSON encoding, there is no much debate for the CBOR encoding.

For the JSON encoding we have different choices.

JSON encoding could be based on explicit labels, or numeric tags.  Both options explored in hackathon.

JSON is pretty verbose, therefore COSE could be more efficent for constrained devices.

Dave Thaler:  expresses preference for more verbose JSON (explicit labels).  CBOR is the choice for efficiency, i.e. numeric tags.

Ciphersuite:  which algm.'s should be in the list?  Which should be mandatory-to-implement (MTI)?

It might be useful to revisit the list of algorithms and how we identify them - we could use different types of representations. My preference is to use EC crypto and pass on the RSA.

IoT motivates the preference for ECC versus RSA.

No objections to using Ciphersuite approach (as opposed to a la carte combination of algm.'s).

Are there any objection not specifying any RSA based cipher?

Giri Mandyam: I am not sure if we are ready to make that commitment.  ECC accelerators are not always readily available for IoT devices.  SW implementations not always feasible in low-cost (low memory) devices.

Nancy: Since we are enumerating values, as we are going to write the specifications, what will be the mandatory to implement ?

Mingliang: There is a difference between the TAM site where you need to support both. We need one mandatory for interoperability.

Nancy: Do you have profiles based on interoperability?

Giri: The reality is that I do not have an ECC solution today for low-cost IoT devices.  I do have solutions for RSA.

Nancy: What I have heard is that it is ok to start with ECC and when we have adoption maybe ...

Mingliang: You need to support at least one by the TA; TAM supports all the ones specified

Dave: TMA does not have a profile so you support both. Which one shall be mandatory or optional (i.e., RSA vs. ECC)

Giri: I hoped we could negotiate the ciphersuites (similarly to TLS)

Dave: We can have the TAM to support everything and/or a negotiation-based approach, but this would require additions to the protocol. Ming simpler approach could be used in the short-term and we can look at the second option later.

Minliang: Agility is important and I like simplicity. We can consider negotiation later.

Hannes: I am going to add an RSA-based suite- later on we can decide how to implement this - I understand you do not want the profile approach.

Mesasge Protection - since we encorporated the manifest we pushed the encryption of the firmare there. The question is: do we need encryption in the messages ? There is not much to encrypt to begin with (most is in the manifest). I am not sure we need it because there is a prtection already between the TAM and the Broker.

EAT (attestation token) can be encrypted at a lower layer.

Dave: Discussion around encryption - multiple layers of encryption exist, so there 

Ming: All data from the TAM is encrypted

Hannes: Today we have a better secuirty - the software is signed and encrypted by the developer, not the TAM, so we have better E-to-E security. I believe we did not loose anything and by refactoring we do not need encryption anymore

Mingliang: From the suit group we import the possibiltiy to encrypt it.

Giri: You do not have to encrypt, you can just sign it. You can also implement the NULL cipher ...

Hannes: EAT provies the signing, in addition you can also do encryption.

Giri: yes, it is possible today to encrypt the payload (which includes the claims). This is compatible with COSE.

Hannes: I am inclined to say we do not provide encryption. You can change from public key crypto to symmetric for performances. We do not have many messages, might not be worth it ?

Certs and Chains:  currently communicated as part of COSE/JOSE header.  Needed for QueryRequest, which conveys TAM chain to TEEP agent.

Not always needed if cached cert chain is current.

Conclusion is that TEEP-P does not need to have any special handling of cert chains.  No objections noted.

SUIT Commands: Another extension I am going to propose. In the first message there is the possibility to convey the capabilities - one of the capability is not related to the manifest (?). It could be useful to ee if you push a manifest to a device and you want to know more about the device features.

Nancy: Are there requirements the we shall be advocating - are there other commands required by TEEP?

Hannes: 

Nancy: When and If we adopt this document. We could use a similar approach in RATS where we could put requirements for TEEP.

Dave: We discussed it yesterday - we will submit issues against the suit manifest document.

Next Steps: Incorporate feedback, add examples in JSON and COSE. It could be useful to schedule an interim meeting?

Nancy: Still an individual draft. Do you call for adoption?

Hannes: Yes.

Dave: There are two questions - should the WG adopt it as a WG item (meets the charter) ? Second - shall we let the open-trust I-D expire ?

No hums against adoption or "not care". We have consesus and we will confirm on the list.

No hums against letting the I-D expire.

[ The open-trust I-D is already expired - no action item ]

Confidential Computing Consortium intro (Dave Thaler)

The TEEP charter mentions that TEEP will maintain a relationship with other SDO's (e.g. GlobalPlatform).

Since IETF 105, the Confidential Computing Consortium was created.  Dave's recommendation is that TEEP coordinates with them.

Linux Foundation hosts this consortium.

Dave provided a summary of their mission.  There is a large overlap between participants in TEEP and membership in the Consortium (including TEEP editors).

There is an Advisory Committee that serves a similar role to the IESG.

CCC also does implementation and marketing.  Protocol development is left to SDO's such as IETF, GlobalPlatform, etc.  3 OS projects have been accepted by CCC.

OS projects accepted:  Enarx, Open Enclave SDK, and SGX SDK.


Anybody can submit projects to CCC in the future at the different levels of abstraction.

The CCC has a taxonomy of confidential computing projects starting from HW (SGX, TrustZone) to u-kernels (e.g. Enarx, Graphene).  In between are native SDK's (e.g. Open Enclave) and Higher-level SDK's (Baidu Rust).

Dave: Useful to have the same people in the two groups when talking about IETF architecture - CCC can implement & market what IETF standardize for instance.

Rich Salz:  does the logo look like the CommonCriteria logo?
Dave:  Don't know.

TEEP-over-HTTP

Dave provided an update on the summary of issues.

Issue #4: relationship to the TEEP protocol - the current draft allows you to use both. You can use also the other media type. This part is done.

Issue #5: Demux to OTrP vs. TEEP - Draft does not explain how to demux if both are supported. which protocol should be used ? Possible solution, remove support for OTrP, or Demux behavior based on media type (works, I implemented), or Demux based on TAM URI (you need two different paths. You still need to learn the TAM URI - but Agent cannot infer anything from the URI itself). No preference between the three options - they can all work.

Dave: What does the WG wants me to do?

Akira: Probably #2 is more HTTP way, but #3 could be easire to implement. Maybe #3 is the preferred.

Is there any interest in #1 ?

Steven: Maybe these are two different questions to be asked sequentially.

Hannes: We could reach out and ask them - I do not really care,but we should reach out to them (Global Platform).

Dave: The best option for #1 is to ask Global Platform people specifically. If they do not support the OTrP from the IETF anymore, then we can just remove all support for OTrP from this document.

Informative Question to get a "direction". If the GP comes back and say they would like to keep OTrP. 
Option #2: One hum in favor for #2. no hums against #2
Option #3: broader support for #3 but active against it.

Rich: I do not like #3. You could just register a well-known identifier (media type in the IANA registry) instead of a configuration item.

Stephen Banghart : prefers option #2

Dave: The media type is used for two purposes - encoding format and for the protocol. There is a preference for #1, and if that does not happen (based on global platform wanting transport for OTrP) maybe a preference for #2.

Issue #1: Terminology alignment - currently we have TEEP/Client and TEEP/Server. There are different ways to interact with the Broker. You can move different parts inside the TEE (Teep Agent; Teep Agent + TEEP/HTTP Client; Teep Agent + TEEP/HTTP Client + HTTP Client). All of these are compliant. I consider the issue close.

Issue #2: HTTP Bindings. Current model uses HTTP initiated by the TEEP Agent and the OTrP comes from the TAM. Anders asks about the case where the Agent is in the Cloud. It is something we want do address ? In IETF 105 we decided to punt for future work - issue resolved (name change and updated the introduction).

Next steps - As soon as we address issue #5 we can move forward (no other issues)

Nancy: Let's wait until December and then we deal with #5 and we can proceed with WGLC.


Enarx (Dave Thaler, on behalf of Mike Bursell) (https://enarx.io)

Enarx was contributed to CCC from Red Hat.

Enarx uses two reference TEEs:  AMD-SEV and Intel SGX.  Enarx "server" is the TEEP Agent, and "Client" is the TAM.

Attestation handshake is followed by code delivery in Enarx model.  Looks similar to TEEP.

Red Hat will come back to IETF on the issue of standardization.

Enarx "keep" is equivalent to a TA.

The model allows for running a webasm binary in the TEE.  A Kubernetes Orchestrator acts as a TAM in their model.

Based on the attestation, the webasm binary is pushed down to the orchestrator.

Giri: Do they have any special protocols or bindings for firewall x-versal?

Dave: Because the protocol is initiated on the right side, they do not need to do anything. All requests are outbound.  This is in contrast to the current TEEP-over-HTTP spec.

If we standardize this model, we have two use cases now - Red Hat and Anders.

Hackathon on Securing the IoT (Hannes) (https://siot-hackathon.github.io)

Small report on the February 17-19, 2020 gathering in Berling, Germany. 

Hardware will be there to play with - please if you know students/people willing to participate.

Nancy: We forgot to put the Transport Milestone. We will do the WGLC in December 2019. I expect for publication in March 2020.

Nancy: Do we need to update since we just adopted the protocl document. We will do a poll to confirm the virtual interim.

Jabber: xmpp:teep@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf106/teep
Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-106-teep
Slides