Minutes IETF108: teep
minutes-108-teep-00


TEEP 108 Session
Monday, July 27, 2020 (UTC)
11:00-12:40     Monday Session I

Chairs: Nancy Cam-Winget, Tirumaleswar Reddy

Meeting started at 11:01
We are using CodiMD for this session.

1.  Agenda bashing, Logistics -- Chairs (5 mins)

Note Takers: Bret Jordan, Michael Richardson, Robin Wilton
Jabber Scribe: Bret Jordan

No changes to the agenda.

2.  Architecture – Ming Pei (15 mins)

Ming is having difficulty joining the call, we will move to TEEP over HTTP and
then come back to Ming when he is able to join.

3.  TEEP over HTTP update – Dave Thaler (25 min)

Draft 07 was posted yesterday. Presenting deltas between draft 06 and 07. This
draft has gone through a working group last call.

5 issues were raised since last review.

Discussed at the April interim meeting:
#21 bcp67bis
    Changed text to be informative
#10 TLS considerations (RFC 7925)
#19 Why allow HTTP?
    New text added in 3 paragraphs. This text is what we agreed to in April

New issues from reviews:
Hannes's review: #15
    Add reference to RFC 6125
    Remove TEEP/ HTTP layer in doc
        No change made
    Are we using cookies
        Added text cookies are not used
    Note that TEEP agent can start with QueryResponse
        Removed sentence that was problematic

Comment from Ben (AD): I'm so used to only seeing 6125 and 7525 for
certificate-validation procedures that it's almost strange to see 2818 listed
as well.

Dave T: reference is there to maintain conformance with BCP56bis (which still
refers to 2818) Fixed an example

#24 Use of HTTP header
    Proposed adding text for codes
        Made change (with a qualification because second sentence of the
        proposed change was incompatible with 204 No Content return code)
    Text says the client uses Accept header but no normative language
    Hannes: Overkill in X-Content-Type, Content-Security-Policy with current
    SHOULD statements
        Proposed to keep SHOULD statements unless Mark Nottingham (as "owner"
        of BCP56bis) says we should make a change. "Still looks good to me"

#22 Redirect handling
    How does a client know to follow a redirect?
    Bcp56bis gives clarity
        Two areas to think about it:
            Proxy requires redirection
            Permanent change of serve (URI)
    No change has been made yet, need WG feedback
        idea is redirect must not be automatically followed
        there may be some cases where we may want to automatically follow
        (rather than assume there must be human interaction) Proposal: simply
        change of MUST NOT insteasd of MAY Objections: Anyone object? Hannes
        Tschoefenig/Akira Tsukamoto: MUST NOT is OK Michael Richardson: Had
        question of how a user would be part of the flow. Dave Thaler: example
        use-case; "my untrusted app install requires a TEE; does that look OK
        to a human?" Michael  R: still having some difficulty understanding
        when an automatic redirect would be appropriate. Next version of draft
        will have a MUST NOT instead of a MAY

#23 Move section 3 (broker architecture)
    Hannes proposed moving to arch draft
        Editors of the arch draft consider this to be the only unaddressed
        issue in /their/ document. Any objections to move to arch document?
        None heard; Akira Tsukamoto and Mingliang Pei approved

#16 Ming's comment on draft 06
    Varius editorial fixes, TEE is a SHOULD (not a MUST)
    Proposed change in scope of TEEP protocol
        Dependencies on RATS and SUIT mean that it would be "unnatural" to
        restrict the scope of TEEP in such a way that it excluded the elements
        those dependencies might require.

We are nearly ready to move to publication once the following two items are
addressed:

1 - Change MAY to MUST NOT for redirects;
2 - Move architecture section to arhcitecture document

3B.  Architecture – Ming Pei (15 mins)
    Failed to get audio back.

4.  TEEP Protocol  – Dave Thaler (25 min)4.  TEEP Protocol – Dave Thaler (25
min)

This document has not gone through WG last call yet

Notable interopt fix, fixed success vs error message type
Currently 9 issues open in github
Version 03 posed July 13 after SUIT hackathon

Issues related to arch document
#2 requested components
#5 ...when have TA binary but need metadata
    Issues with passing in information
    Options
        a) attestation claims (what the doc says now)
        b) separate QueryResponse field
If no objections, Dave suggests (a), as it does not require any change to the
current architecture doc. (No comments in the chat or queue)

#16 List of no-longer needed TAs
    How to remove TA. Does a TAM know that there are no apps calling in to a TA
    anymore. Should we support passing a list of TA that are no longer needed
    since only the TAM is able to clean up no longer needed TAs. Dave proposes
    (a) which is a change to the arch document, doing it via an attestations
    claims.

Options to support this scenario:
        a) attestation claims
        b) separate QueryResponse field
        c) do not support

No one objected to moving forward with (a): Hannes Tschoefenig, Russ Housley,
Akira Tsukamoto and 大居 司 (Tsukasa Oi) indicated support.

Issues related to suit-manifest
#41 Add SUIT manifest examples?
    This could help implementers
Comment from Hannes Tschofenig: TEEP examples of SUIT should be described in
the TEEP protocol document.

Brendan Moran: They should be lazily instantiated. Once you have a security
domain. We discussed this at the SUIT interim meeting.

Add examples to TEEP protocol spec or SUIT manifest document. Brendan, this is
very specific to TEEP, lets put it in the TEEP protocol spec which is Dave's
recomednation as well.

Questions/comments from Ben Kaduk and Hannes Tschoefenig.: Brendan Moran
developed a tool to create manifests; does it already include functionality to
*validate* SUIT manifests? Hannes Tschoefenig: given the multiple layers in use
(COSE/CBOR/CDDL/SUIT), verifying the example manifests is hard.

Summary: Keep it being implicit

#13 Vendor-specific attestation
Can it be used with SGX. SGX is already in use.
Should TEEP protocol

(a) support ervidence format agility (not just EAT)
(b) Require wrapping other things in an EAT
(c) Not support existing formats

Dave: (a) would be my preference
Hannes, Tsukasa, Kuniyasu Suzuki all in favour of (a).

Hannes Tschoefenig: has added #43 to the issue list in github:
https://github.com/ietf-teep/teep-protocol/issues/43 Issue description: "If a
TA installation that contains a SUIT manifest requires further interactions to
perform a complete installation of dependencies then the TEEP Agent has to be
given the ability to tell the TAM that further interactions are needed."

4a.  Architecture – Ming Pei (15 mins)

WGLC on version 08
Russ Housley Review
Daniel Migault review
Updated 09 12

Closed 17 issues

Open issue: #203 shouild section 3 of teep-over-http doc move to arch doc?
    Discussed previously and have wg agreement

Dave is taking over for Ming due to audio issues

Review closed issues:
#170 Provide two examples
    Added text

#172 Application vs Appication component
    Changed text

#173 Revise defintions of "CA"
    Changed text
    Hannes Tschoefenig/Ben Kaduk/Russ Housley: can/should  we check this for
    consistency with the decision of a CA in PKIX RFC? Ben Kaduk... RFC4949?
    [RFC 4949 contains the following definition:
      1. (I) An entity that issues digital certificates (especially
      X.509 certificates) and vouches for the binding between the data
      items in a certificate.
      2. (O) "An authority trusted by one or more users to create and
      assign certificates. Optionally the certification authority may
      create the user's keys."]

#174 Use one term among "TA software author", "TA binary signer", and "TA
signer".
    Changed "TA software author to "TA developer"
    Changed "TA binary signer" to "TA signer"

#175 Add itegrity proteciton in section 4.4
    Changed text

#177 Section 5 wording about key transport and key agreement
    Changed text
Comment from Hannes Tschoefenig: If we add an example to the TEEP protocol then
the topic of key transport/key agreement will be clearer.

#178 Section 5.1 use of raw public key in TAM
    Changed text

#183 Section 9.7 add setence for making a device cert that never expires
    Changed text

#185 Discussion to cover compromised trust anchors and compromised intermediate
CAs
    Changes made

#201 Daniel Migault's comments mostly editorial
    Changes made
Daniel: The draft explains the importance of being able to trust the outputs of
the Trust Anchor, but says less about the need to trust the output of the TEE;
Dave T.: wording updated to describe trusted displays (e.g. a typical trusted
payment/banking terminal) as the execution environment. Hannes: Referring to
trusted displays is useful because this is a common use case in a
TrustZone-based system)

#203 We talked about this one already

5.  Hackathon Report – Kohei/Akira (15 min)

No hackathon during IETF 108
SUIT hackathon had 3 projects related to TEEP
* Use of SUIT manifests in TEEP (Dave Thaler)
* Encrypted TA binaries (Hannes Tschoefenig)
* TAM and TEEP Agent using SUIT Manifest (Yuichi Takita)

TAM and TEEP Agent using SUIT Manifrest
What we planned - Add SUIT to TEEP implementations
What we achieved - Implementation of handling TEEP-P messages
What we learned - Need more example of TEEP-P messages and SUIT Manifest

Current TEEP implemnations list
    TEEP Devices
        Dave, Hannes and Libteep
    TEEP Servers (TAM)
        Dave, Hannes, tamproto (NodeJS)

TEEP- device status on RISC-V
    AIST have been working on teep-device prototype
    Working to generalize implmenations to QEMU
    Porting to RISC-V
    All in C/C++
    Akira: gave a review of what they have been doing and the status of of a
    TEEP-device on RISC-V (incl. description of the three privilege levels
    available in RISC-V: U-, S- and M-modes, and         the relative placement
    of trusted functional blocks in those levels, in untrusted Linux and      
      trusted Keystone environments)

6.  Milestones review – Chairs (15min)

Nancy: Need to update our milestones
    When will we be ready for a wglc on the protocol
    1 - Do document owners think the TEEP Protocol (Solution) document can be
    ready before November? Dave Thaler: certainly not for August; November may
    be okay, but agressive.  We are still in the middle of implemenations. We
    do not have text for open issues. Dave: we should set milestone to March
    2021 2 - Architecture document: Dave Thaler; noted two issues to be
    resolved, but those can be addressed during IETF 108, so August 2020 is
    still realistic. Hannes: suggests moving to September Dave T: fine; it can
    always be submitted to the IESG earlier if it's done earlier. 3 - Transport
    document:
        Tirumaleswar Reddy: it has a couple of open issues but these have been
        discussed and are           straightforward to resolve Dave: we should
        have the same due dates for transport as arch, they are both in the
        same           state.
Nancy (chair): any objections to setting the same schedule for Transport as for
the Protocol? We will confirm on list.

Meeting closed at 12:42 UTC

We did not have time to address the following agenda item.
next time but please review. thanks
7. Test tool for detection of potential DDoS vulnerability of IoT devices as
well as TEEP enabled devices  - Sorin Faibish (if time allows) the draft. Sorin
Faibish