Minutes IETF114: teep: Thu 10:00
minutes-114-teep-202207281000-00

TEEP IETF 114

• Chair: Nancy Cam-Winget (NCW)
• Notes takers: Ned Smith (NS), Paul Wouters (PW)
• Agenda bashing

• Architecture - Mingliang Pei (MP) Dave Thaler (DT) will be
  presenting

  • Section 3.3 - changes made to this section but didn't break WG
    consensus
  • Section 9.3 - modified replay message handling
  • Section 9.4 - Clarification of Root CA vs. Trust Anchor. As a
    cert, it doesn't have to be a root CA.
  • Definiton of trust anchor provided. draft-17 contains the new
    wording which leaves open the definition to allow for other
    structures besides certificates.
  • Section 4.4 - Clarification about personalization data
    protection mechanisms. Ben (area director) suggested separating
    these concepts in the document for added clarity.
  • Nits - Several nits were addressed having to do with sentence
    structure, editorial, etc... AppStore vs. TaStore terms seems to
    use these terms interchangably a definition of AppStore was
    added to help clarify.
  • Threat Modality - Section 1 text includes the term "powner" but
    some disliked it. Brendan Moran suggested alternative text which
    is more precise.
  • All these changes from AD review have been applied.
  • Paul (current AD) - We should move the document forward. Please
    Q it up.

• Hackathon Report - Akira Tsukamoto (AT)

  • First meeting since hackathon in Berlin Feb 2020.
  • Objective and Plan - Tackle adding support for EAT.
  • Behavior when selected-cipher-suite is empty in QueryResponse.
    Conclusion among hackathon participants was to send
    SUIT_reports in the QueryResponse. PR187 contains details.
  • Ability to support both Evidence and AttestationResults.
    QueryResponse needed to support both Evidence and
    AttestationResults therefore the message payload was generalized
    to support both types of information.
  • Additional message for Attestation. Decision to use 'manifest'
    in 'evidence' in QueryResponse instead of 'sw-version' for TEE
    firmware. See PR2??, PR221 and PR231 for details.
  • Supported cipher-suites made mandatory in QueryRequest. See
    PR222.
  • Running cddl tool for CDDL grammar check. CDDL (RFC8610) Cddl
    diagnostics are cryptic. Need help to decipher. Issue198 has
    details.
  • Brendan Moran (BM): There is a note in suit draft that explains
    to concatenate the cose cddl to the end of the suit cddl to make
    is a proper grammar. Open to feedback.
  • AT: Concatenation should work (it seems to work), there are
    dependencies that require a github repository to do things
    manually. There were 4 lines of cddl needed to add it manually.
    Possibly a readme should be created?
  • BM: COSE draft has instructions for cddl extraction, but seems
    unusual.
  • Pengling Yang (PY): The problem isn't a COSE definition problem
  • AT: agree.
  • Michael Richardson (MR): There are other ways to deal with it,
    brief explanation of how to do this using curl and other tools.
    other CDDL tools produce C header files.
  • AT: Some of the cddl files are not found anywhere.
  • MR: Poke the peole in the other places to also apply the BKM for
    extracting the cddl.
  • AT: concatenation of cddl files is something that needs more
    attention to make it really useful. Nevertheless, there was
    great progress made. Some parts of the implementation are needed
    but it looks pretty good so far.
  • AT: Documented in slides a procedure for using cddl tooling.

• Teep Protocol - Dave Thaler (DT)

  • DT: At hackathon there were 6 known implementations with 5 of
    the implementers sitting at the table. Very productive to have
    all the implementers present to agree on what spec changes
    should be needed. There were zero open issues in the spec that
    had no text. However, 3 new issues came up later.
  • NCW: Thanks to all those how contributed.
  • DT: Send your implementation information to TEEP chairs.
  • DT: Presented a slide with issues from last meeting - will not
    discuss these.
  • DT: New issues since last meeting.
  • #226 - IANA question about freshness mech registry. Where should
    the new registry be located? Is it a TEEP thing or a RATS thing.
    It may not be TEEP specific, could be RATS. Options: (1) Keep it
    (2) move to RATS Interactions Models - covered in RATS during
    open mic session. Draft isn't posted yet, but a pending draft is
    expected.
  • Attestation - #215 may require one more message for attestation.
    DT showed a slide depicting a hybrid background_check message
    flow that has the TAM as intermediar between Verifier and
    Attester (TEE). The question is which TEEP message is used to
    convey AttestationResults messages. To fix this, the 'update'
    message was modified to include attestation-payload-format and
    attestation-payload entries to the options map within the update
    message.
  • #224 - Clarify how TAM distinguishes Evidence from
    AttestationResults in QueryResponse. DT showed slide of hybrid
    background-check model. Added a rule that says if
    attestation-payload-fromat is recognized as AttestationResult,
    then that's what it is, otherwise treat it as Evidence. If
    Evidence, then it can be forwarded to a Verifier somewhere.
    There are 3 states: (1) can't trust the QueryResponse, try
    updating TEEP Agent to any dependencies (2) Attestation
    suceeded, but TC list is out of date, try updating needed TCs
    (3) Attestation succeeded - no change needed.
  • Daniwl Migualt (DM) - Do you pass the payload or is there an
    explicit message.
  • DT: There is a media type in the parameters that disambiguates.
    Ref RATS draft 'EAT Media Types'
  • #227 - SUIT Component Identifier isn't Unique. Once there is an
    Attestation Result then 3 cases:
  • (1) tc-list => [+tc-info], ; old cddl. New cddl: tc-list =>
    [+system-property-claims]. The new approach allows inclusion
    of a suit manifest / parameters.
  • (2)
  • (3)
  • #189 - Four ways to get properties of the TEE.
    AttestationREsults - may be burdensome places new duties on the
    TAM, SUIT Reports - relies on TEE generating SUIT report at
    boot/load time also burdensome for some TEEs, TC List - meant
    for components that can be updated by TEEP - didn't define HW as
    a trusted component, Some new field. Using a new field that is
    similar to TC List?/SUIT reports? was added.
  • MR: SUIT Reports at boot time too burdensome, but doing a subset
    of SUIT reports later on is OK? What is making it hard?
  • DT: I didn't implement it. Is there another implementer who can
    clarify?
  • DT: The SUIT WG meets later today, this would be a good topic to
    take there.
  • BM: Generating a SUIT report implies 2 things (1) booting a
    device using SUIT manifest. If not using a manifest then not be
    the right answer. If not using a manifest then you can (2) Using
    system property claims. Directly tied to SUIT report. Maybe just
    borrowing attestation claims can be done even if not using
    Attestation Resluts.
  • #221 - Reliably getting TEE FW properties. 4 possible ways to
    get TEE properties. (1) AttestatonResults. If not designed for
    human consumption (2) SUIT Reports. maybe too burdensome for
    some TEEs (3) TCList. (4) Some new field. Option 1 determined to
    be the best approach. DM showed a slide with matrix of EAT
    claims across 3 EAT drafts. draft-09, draft-09, github version.
    sw-name and sw-version changed to 'manifest' which refers to
    SUIT mainfest use of name and version. Today there are no
    required claims, can simply say 'good' or 'bad'. Optional claims
    can be included to provide additional context. No prohibited
    claims. Text added to spec to clarify this and the impact to
    TEEP Agent and its dependencies. See TAM behavior section.

  • #220 - Ciphersuit negotiation. 5 problems identified.
    a. Unclear which signature COSE_Sign or COSE_Sign_1 is to be
    used
    b. Contradiction in ciphersuite defintion
    c. unlear what specific ciphersuite combinations are mandatory

    d.
    e.
    * Fixes - Change $ciphersuite to be explicitly supporting
    extensions
    * * Remove MAC and Encrypte algs into future documents

  • • Remove COSE_Sign - can be added later
  • • Fix contradiction between CDDL body
  • • ???

  • #220 Mandatory ciphersuites.

  • • teep-ciphersuite-sign1-es256
  • • teep-ciphersuit-sign1-eddsa

  • TAM must support both, TEEP agent can support either

  • Ciphersuites can have multiple ordered operations
  • These two don't define encryption. Encryption can be done at the
    SUIT payload layer.
  • #222 Make supported-ciphersuites be mandatory
  • • supported-ciphersuites entry in query-request is not
      mandatory. This is a breaking change, but everyone agreed to
      it.

  • #222 Example in appendix.

  • #234 Which TEEP messages are protected?
  • • Section 8 - text seems wrong since selection of ciphersuite
      happens after QureyResponse is received.
  • • Q2: Does that mean the QR can't be protected? Can receiver
      figure it out from a COSE object? (y/n?) Cand Attestation
      payload be encrypted (y/n?) Can SUIT report be encrypted?
      (y/n?)

  • BM: What does the key exchange look like? Seems challenging.

  • DT: Agree. Maybe just don't put sensitive information in the
    SUIT report?
  • BM: You need a public key for the recipient correct?
  • DT: Does an error in response to QR be protected? Perhaps. If
    TEEP Agent was able to select a ciphersuite from the TAMS
    supported-ciphersuites then use it to protect the error message.
    Otherwise, us a ciphersuite mandatory for TEEP agent to support.
  • AT: An error message could be used by attackers to learn new
    information.
  • DT: Yes, this is an important consideration. Opinion is it might
    not be applicable to TEEP messagning.
  • MR: We have enough bad experience from IKEv1 to know that error
    messages are needed to fix problems. The attacker can enumerate
    them and figure it out. The down side wasn't a good trade-off
    between security and usability.
  • DT: One more slide.
  • NCW: Having technical difficulties
  • DT: Question that came up when a number of TEEp agents ar manged
    by the same TAM, but none need the trusted component. The
    component is deleted, but all the other TEEP agents should be
    forced to be deleted. TAM has SUIT manifest references to
    repositories. Use the update message to pass the SUIT manifest
    with delete directives. A version of SUIT manifest that is
    different from the original is needed. So you have to construct
    a new one with manifest sequence number that is +1 hence there
    are multiple versions of manifests that has to be managed.
  • DT: What is device has a component the TAM doesn't know about?
    Not specified in SUIT.
  • DT: Ken? proposed adding uninstall directives into SUIT
    installation manifests. If SUIT does that we could add back in
    ability to delete by ID.
  • update message has manifest-list => [+ bstr.cbor
    SUIT_Envelope]
  • BM: have you threat modeled this yet?
  • DT: No.
  • BM: How many TAMs can a device have and how are their
    reponsibilities assigned.
  • DT: OTRP uses term 'trust domain' there is one TAM per trust
    domain.
  • BM: Dependencies across trust domains are forbidden?
  • DT: Yes, but it depends on the dependency.
  • BM: What lives in the uninstalled instructions? Really unclear.
  • DT: I think the install directives are an explicit set of
    commands that 'should' be the opposite of dependencies.
  • BM: A few examples of what goes into an uninstall directives the
    SUIT manifest experts can review.
  • DT: Rattled off a few examples.
  • BM: Could these be component IDs?
  • DT: Maybe.
  • NCW: move topic to mailing list
  • MR: Why do we have a case that the TAM doesn't know about it?
    There is a problem with the components that the TAM is willing
    to accept (but has debug instrumentation), now the component
    gets deleted. The TAM doesn't know that. It allows debugging to
    be done without disrupting the TAM.
  • DT: The code comes from one TAM, personalization data comes from
    another TAM. The TAMs are not mutually trusting.
  • MR: Reference counted hard links are 50 yr old technology. It
    isn't a fundamentally a hard problem.
  • DT: Agree. There is wording to the effect that things can be
    reference counted.

• Teep Usecases for Confidential Computing in network - Penglin
  Yang(PY)

  • PY: Motivation - Conf Computing (cc) raises several questions
    for TEEP

    • What is the arch of cc in network?
    • What kind of app packages a network user should use?
    • What kind of steps network user should follow to deploy
      application packages?

  • PY: cc instance type - slide showing cc containers. Process
    based, Container based, etc...

  • PY: slide showing notational architecture. TEEP roles integrated
    into cc containers.
  • PY: Slide showing packages and deployment steps. Table
    containing package modes and types of TEE environments (UA, TA,
    PD). Three CC instances span 3 HW architectures and defines
    deployment strategies for each.
  • PY: Slide showing TA and PD as separate packages and how to
    deploy them.
  • PY: Slide showing a scenario with TEEP and cc overlayed on top
    of each other.
  • PY: Slide showing Summary.
  • PY: Processing remote attestation may be facilitated by RATS.
  • PY: CAll for adoption?
  • Hannes Tschofenig (HT): Supports adoption. There is a
    possibility to describe mapping of cc use cases to TEEP arch.
    Explaining this could be quite helpful for developers who are
    not familar with TEEP.
  • DT: 2 things in presentation that are new, valuable (1) the use
    case form for where is the TEEP agent. This is a use case for it
    being neither in the cloud or in the same box. Rather its in an
    infrastructure box. (2) The arch document describes bundling,
    but there doesn't have to be an untrusted app. There can be only
    trusted apps. These are new ideas the use cases highlight.
  • Daniel Migualt (DM): If we have a document that illustrates
    discussion in the WG would be helpful. But we should not try to
    provide an exhaustive list of every deployment option.
  • NCW: This is a useful addition, but as a standards track
    document does it make sense? Chair recommending an informational
    RFC.
  • DT: What might be useful is informmation not standards track,
    but may be useful to combine the cloud case with the network use
    case documents. Common thread is both use cases don't have a UA
    (untrusted agent).
  • NCW: Does it make sense to adopt or wait?
  • DM: Doesn't have a strong opinion, something informational.
  • NCW: Recommendation as chair is informational.
  • PY: Intended to be informational, oversight that it is standards
    track.
  • DT: The WG can decide how many milestones the document is plit
    into. Upd to the AD to decide.
  • Sorin Faibish(SF): Two interesting use cases that should be
    included, use of containers could be a security problem - hence
    should be a different use case. Emphasizes use cases based on
    cloud. But these may have security challenges.
  • Christopher Inacio(CI): Reacting to Sorin, what is meant by
    container security challenges. CI has research project using
    formal analysis tied to HW RoT with a hypervisor written in a
    formal language. Interested in understanding risks.
  • NCW: We have 2 minutes. What is the readiness of the document?
  • Poll: Is there interest in waiting to include the two use cases
    before doing adoption. No clear consensus.
  • AD: It doesn't matter.
  • HT: +1 - lets just do the call.
  • Poll: Call for adoption. Unanimous support.
  • NCW: Change the draft to informational and resubmit it.
  • DT: He will post the github copy and reduce issues to 3 open
    issues.
  • NCW: Will move discussion to the list regarding WGLC.
  • Adjourned 12:03