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