Minutes IETF115: teep: Wed 15:00
minutes-115-teep-202211091500-00

Meeting Minutes Trusted Execution Environment Provisioning (teep) WG
Date and time 2022-11-09 15:00
Title Minutes IETF115: teep: Wed 15:00
State Active
Other versions markdown
Last updated 2022-11-17

minutes-115-teep-202211091500-00

IETF 115 Session III November 9 2022
TEEP

Chairs: Tiru Reddy, Nancy Cam-Winget
Note takers: Pieter Kasselman, Chris Inacio

Agenda bashing, Logistics -- Chairs (5 mins)

  • Only 90 minutes available today
  • No time for new items today

Architecture – Mingliang Pei (20 mins)

• Draft: draft-ietf-teep-architecture
• Issues: https://github.com/ietf-teep/architecture/issues

Hackathon Report – Akira Tsukamoto (15 min)

  • PResnetation here:
    https://datatracker.ietf.org/meeting/115/materials/slides-115-teep-teep-hackathon-02.pdf
  • 7 Participants

  • Evidence of Attestation Result in EAT Profile

    • TAM does not process the attestation-payload in order to verify
      it, it can just process the payload-format field

    • Muhammad Sardar(MS): What exactly do you mean by payload? It is
      an undefined term in TEEP.

      • It's a binary

    • MS: What exactly would it mean for SGX?

    • Dave Thaler: The word "payload" - it's the name of the field in
      the message.

      • payload - byte string in the message
      • payload-format - the type of byte string in "payload"
      • For SGX - (way too fast to write that down); the payload
        would be an SGX specific type (not described in the draft,
        SGX specific) that would be processed in/by the SGX
        implementation

    • Hannes: will send a link to the list on this topic (about using
      newer CBOR features for ? payload feature)

    • Thaler: that's not adopted yet

  • Use CBOR tag or not on SUIT nvelope

    • Decided not to use SUIT envelope

  • Support for ES 256 and EdDSA

    • Will proceed to support it

  • Fixing CDDL Syntax errors

  • SUIT digest unneeded-manifest-list

    • Conclusion to use SUIT_Component_Identifier

  • Impact of hackathon/Progress

    • 8 PRs
    • 4 new issues (see slide 12)

TEEP Protocol and transport drafts – Dave Thaler (40 min)

• Draft: https://datatracker.ietf.org/doc/draft-ietf-teep-protocol/
• Issues: https://github.com/ietf-teep/teep-protocol/issues

  • Deck here:
    https://datatracker.ietf.org/meeting/115/materials/slides-115-teep-teep-protocol-00.pdf
  • #234, 251: Which TEEP messages are protected with which cipher
    suites

  • Unrecognised TEEP messages

    • What to do if the spec is violated?

      • Drop message if not valid and reply with an error

    • What does the TAM do?

      • TAM can fix errors (software updates)
      • May do logging or suggest new version to use

  • Use of SUIT

    • Mike - tCOSE does support EdDSA
    • Thaler - could not use it for signatures - couldn't use it with
      queryt reqest messages.

  • Uninstalling trusted components

    • References SUIT meeting before the TEEP meeting

  • SUIT_Evelope vs SUIT Envelope Tagged

    • May want to use something that is not CBORbased
    • What people need is in the base document, everything else in
      extension doc

  • SUIT digest in unneeded-manifest-list

    • SUIT Component identifer
    • Not in the draft yet
    • Added component ID for root manifest

  • SUIT reports can contain sensitive information

    • Add privacy considerations
    • Russ Housley: heard something different. Lots of places they
      want this in plaintext.
    • Thaler: if sneaker netting, who's responsbility is it to encrypt
      that
    • Bredan: You want a statement in security requirements of
      suit-report that says if there is anything senstive you need to
      encrypt that
    • Brendan: MTI document, is only for constrained device update
      only       its covered in there.
    • Thaler: Then should this be covered in the TEEP protocol?
    • Brendan: Yes
    • Thaler: Any objections to having it in TEEP not in SUIT-report?
    • [none heard]

  • Use of EAT

    • Which ciphersuite to use (sign and then encrypt)?
      • A good ciphersuite is the one already implemented
      • Destination if SUIT report and EAT are different - one goes
        to verifier, other goes to verifier
      • Thaler: Recommends they should be the same, but still need
        to pick something
      • Encryption algorithms havbe not ebeen discussed
      • Brendan: Should we use different ones from the MTI doc in
        SUIT? Some implementor already has hard requirement for RSA.
        Would be inclinde to ask what they require as they are not
        in the draft.
      • Brendan - this is not about key exchange just bulk
        encryption. You don't need to deal with out of order arrival
        of data. This should not be an issues - use the AEADs. If
        you can afford e.g CCM that is the way to go.
      • Russ, Hannes: +1 on that recommendation

  • EAT Profile - all claims are optional

    • Thaler: Propose 5 mandatory claims, one optional (the nonce)

  • EAT Manifest Claims in TEEP Profile

    • Thaler: Propose use of SUIT_Refernece (nods)

  • Sample EAT Token

    • Udated

  • Relationship between TEEP EAT profile and AR4SI (slide 18)

    • Discussed 5 options, None ideal
    • Thaler - prefernece is for option 4 or 5.
    • Call for feedback.

    • Penglin: TAM can be verifier (collapse roll) - this will
      simplify

      • Thaler - dont want to force it, but allow yes.

    • Akira Tsukamoto: prefer option 4 between 4 and 5; easier to
      update draft than too. How implement on SGX, not
      clear/informative enough in the draft.

    • Hannes: Do we need to cover passport and background check.
      Nobody forcing to cover full architecture from RATS
      • Thaler: TAM is a specific Relying Party (background checks).
        Things more complex when using passport checks. Need to
        accomodate both. TAM could send two queries to the verifier,
        but will need different nonces (timestamp may help avoid it)

  • How does omitting the EAT profile work with bis documents?

    • Resolution proposed, no discussion

TEEP Use Case for Confidential Computing in Network – Penglin Yang (10 min)

•https://datatracker.ietf.org/doc/draft-ietf-teep-usecase-for-cc-in-network/

As we are over time, question on the Protocol draft readiness:

  • Nancy: Are we ready to do early review - take it up on the list

    • Thaler: based on those in the comments room answer is possible
      yes.

  • Ira: (in Zulip/Jabber) NIST definition of secure channel: From NIST
    Glossary: secure channel is "A path for transferring data between
    two entities or components that ensures confidentiality, integrity
    and replay protection, as well as mutual authentication between the
    entities or components. The secure channel may be provided using
    approved cryptographic, physical or procedural methods, or a
    combination thereof. Sometimes called a trusted channel." from
    SP800-90A-Rev1