* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Teep Status Pages

Trusted Execution Environment Provisioning (Active WG)
Sec Area: Roman Danyliw, Benjamin Kaduk | 2018-Mar-09 —  
Chairs
 
 


IETF-108 teep minutes

Session 2020-07-27 1100-1240: Room 5 - Audio stream - teep chatroom

Minutes

minutes-108-teep-00 minutes



          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
          
          



Generated from PyHt script /wg/teep/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -