Minutes IETF106: teep
minutes-106-teep-00

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