Minutes IETF102: suit

Meeting Minutes Software Updates for Internet of Things (suit) WG
Title Minutes IETF102: suit
State Active
Other versions plain text
Last updated 2018-08-01

Meeting Minutes

   IETF 102 SUIT Working Group in Montreal, QC, CA
Wednesday, 18 July 2018 at 09:30 EDT

Session Chairs:
   Dave Waltermire
   Dave Thaler
   Russ Housley

Note Takers:
   Jessica Fitzgerald-McKay
   Carsten Bormann

Jabber:   xmpp:suit@jabber.ietf.org?join
MeetEcho: https://www.meetecho.com/ietf102/suit
Etherpad: https://etherpad.tools.ietf.org/p/notes-ietf-102-suit

   1) Agenda bashing, Logistics -- Chairs (5 mins)
   2) Hackathon Report -- Hannes (15 mins)
   3) Suit Architecture --  Authors
      - draft-ietf-suit-architecture
   4) Suit Information Model -- Authors
      - draft-ietf-suit-information-model
   5) Suit Manifest Format -- Authors
      - draft-moran-suit-manifest
   6) Next Steps -- Chairs

Agenda bashing, Logistics -- Chairs

- WG Update
  -- Architecture and information model adopted by WG
  -- Virtual Interim on 6 June 2018, focused on architecture and manifest
     --- Minutes have been posted
  -- Hackathon projects at the interim and at IETF 102

- Milestones
  -- Missed serialization formats milestone, but doing fairly well on
     other milestones
  -- Need to focus on the manifest information model milestone, and need
     to create the missing milestone for the architecture document

Hackathon Update (Hannes Tschofenig)

- Demonstrated ability to generate manifest, encode with CBOR, sign
  with COSE, and verify with SUIT prototype board
- Board manufactured for Hackathon (see picture in slides)
- Writeup produced by Jaime -- useful for newcomers
  -- See https://etherpad.tools.ietf.org/p/FUIETF102
- Lessons learned:
  -- Need easier set up process
  -- Need to release new COSE implementation with a different license
  -- Good to have a stripped-down CBOR implementation for decoding the
     manifest on the embedded platform
  -- Traversing some of the data structures with the tinyCBOR API is
     not intuitive
  -- Want to focus on producing more running code and increase
     involvement from the WG
  -- Will start discussion on list for planning for IETF 103 Hackathon

Architecture (Hannes Tschofenig)

- Lots of changes in draft-moran-suit-architecture-03
  -- New terminology; see three slides in presentation
  -- Updated operating modes
  -- Device firmware update examples
  -- Additional coauthor (David Brown)
- Settled on terminology for authors and communicators
  -- Device/network operator split motivated by discussions in London
     and interim; may need to introduce more players
- Architecture includes concept of a Trust Provisioning Authority (TPA)
  to distribute trust anchors and authorization permissions
- Need to document in greater detail various trust scenarios
- Use cases might drive particular solutions. Hannes says the use cases
  are in the information model document.
- Brendan points out that the TPA will often be the OEM, but not always.
  The TPA allows for a layer of abstraction for this role to enable
  scenarios such as customers deploying their own trust anchors.

  Erik: Try to separate the issues, don't conflate them.
  Jonathan: Can we coordinate terminology with other RFCs that include
     trust anchors?
  Hannes: They are different; coordination is a long shot.
  Carsten: Maybe we can describe how they are different.

- Three modes: client-initiated, server-initiated, and hybrid.  NATs
  and similar middleboxes might dictate what mode can be used.

  Dave Thaler: Confusion previously brought up by others about term
  "mode" implying a device needs to support multiple modes, maybe "model"
  would work better to be clear that's not the case.

- Walk through some examples

  Keith Moore: May have to update low-RAM devices in slices; SoC
     encompasses a wide range of systems, including the BeagleBone.
     This needs a lot of work, and I'm happy to provide input.
     I can help write improved use case examples.
  (David Brown tried to make comments over meetecho, unintelligible)

- Human rights review (link in slides) recommended encryption of
  manifests when a device is easily associated with a human.
  -- Proposed text on list, but issue remains open.

  From jabber: Group needs to decide at what level to set requirements.
  Dave Thaler (as individual): Be careful to not overcomplicate the
     architecture; can just encrypt the manifest as a binary blob and can
     take it from there recursively.

- Next steps for this document
  -- More editorial cleanup
  -- Incorporate feedback from this meeting
  -- More text about device interactions and bootloader design
  -- Better alignment with information model

Information Model for Manifests

- Use cases:
  -- Multiple Network Operators with a Single Device Operator
  -- Single Network Operator with Multiple Device Operators
  -- Shows that a single signature is not enough to guarantee that
     requirements of the device-controlling entity are met.
- Incorporated terminology from the architecture document.
- Added new use case for rollback, which allows distribution of new
  manifest pointing to old firmware. Capability implicitly allowed in
  earlier versions of the specification; this use case makes it explicit.
  -- Question of whether this opens you up to a downgrade attack.

  Hannes: The risk is managed via the manifest sequence number.
  Brendan: The provable intent of the author helps here too.

- Storage Location element tells device which component is being
     updated (two storage locations, file system or flash).
- Component Identifier indicates which part of the storage
  architecture is the target of the payload.

  Carsten: Earlier you used the phrase "part of the component". That
     concept needs to be clarified.

- Some conditions need to be checked before installation (identifiers,
  time, precursors), but other conditions need to be checked after
  -- Still need to reflect split of pre- and post-conditions in the
     information model.
- Directives, Aliases and Dependencies need to be combined into one
  element in the manifest.

  Henk Birkholz: In my earlier contribution today, I was copying this,
  but I have no clue about its intended semantics.

- Next Steps for this document:
  -- Fix inconsistencies between manifest format and information model
     (and, in the future, start with one document and then split the

  Henk: Need to incorporate concept of major and minor versions.
  Stephen Banghart: Be consistent with capitalization of "must"
  Hannes: Still deciding what is mandatory to implement.

CBOR Manifest Serialization

  Carsten: This is the data model?
  Brendan: Yes

- Open issue: Primary object is array or map?

  Brendan: I think it is an array because most fields are mandatory.
  Carsten: Agree, this is a stable set of fields.
  Henk: 5 are mandatory, 7 are optional.
  Dave Waltermire: Prefers map to reduce branches and add extensibility.
  Carsten: If you need to see whole picture, map is fine. Array is
     beneficial if you can do processing without seeing whole thing.
  David Brown: Document needs to identify the processing sequences.
  Carsten: Planning to define slightly different canonical encoding in
     CBOR WG.
  Ben: Have to keep in mind that a new extension might be critical.
  Henk: Yes.
  Brendan: I like the idea of a pull parser.  Maybe we can combine these
     concepts. Put elements in order needed by device to get best of both
  David Brown: Maybe we can contribute [something] back to CBOR.
  Henk: We could use a 2D array, but why, when there are maps.

- Open issue: Should the manifest graph be a tree?

  Carsten: Trees allow tying control flow to sequence in which they come
     in, easier to process.
  Henk: Agree.

- Open issue: One digest for the whole manifest?
  -- Should sections be severable?
  -- COSE has no algorithm identifiers for digests, do we need to create
     an update?
  -- Encrypt manifest?

- Tree Process Description (Slide 5)

  Dave W.: Have you thought about namespace for component identifiers?
  Brendan: It's like an OID (object identifier).
  Dave W.: Need to clarify that.
  Dave W.: Think about how to manage extensions, follow common pattern.
  Brendan: Negative numbers for extensions, Positive numbers for
     registered extensions (e.g., specification required)
  Henk: Use CDDL. Also, I couldn't compile it due to name discrepancies.

- Description of installation process in manifest (Slide 13)

  Hannes: Need to sync up information model and data model.
  Chairs: Let the authors do one more update, particularly regarding
     map vs. array, and then we will do a call for adoption.
  Brendan: Works for me.
  Hannes: Preference in room for map.
  Dave Kemp: Some serializations provide ordering.
  Chairs: Ordered vs. unordered can be addressed in information model.
     Ordering important for signing.  Need to discuss and define where
     ordering does matter, and prioritize documenting these concepts in
     the information model before updating the data model.  Could be
     done in parallel if being done by different people.
  Henk: Can register CBOR tag if ordered map is important to the WG.
  Brendan: Ordered multimap has benefits.
  Henk: ... and disadvantages.
  David B.: Order is important for signing and making poll parsing
     easier.  Processing steps may have different actors, how do we
     address that?
  Brendan: Each actor defines a new process tree, telling recipient
     what to do.  How deep could that queue get?
  David B.: Maybe 30.
  Brendan: 30 is hard for a constrained device; might manage 3.

- Current Changes: updates from previous versions (Slide 15)
- Guiding principle for severable test is that severable part is used
  by humans, not devices. So, it lives outside the authenticated container.
  (Slide 17)

  David B.: Are we creating a CBOR tag for this?
  Brandan: Yes.
  Dave W.: CoSWID is targeted toward management systems, perhaps we can
     use that for some of the human-focused capabilities, and leave manifest
     work as machine-focused.
  Brendan: Great.
  Henk: CoSWID has firmware resource extension; we detached it and sent
     it to SUIT. It was submitted last night. It is based on maps.
     (See draft-birkholz-suit-coswid-manifest)
  Hannes: Aren't you an author of the information model?
  Henk: Yep.

- Split payloads in multiple parts, allowing multiple payloads to
  be used (Slide 20)
- Split conditions into pre- and post-conditions (Slide 22)
- Component identifier replaced storage identifier (Slide 23)

Wrap Up
- Virtual interim will be mid-to-late September
  -- Chairs will send out Doodle poll on dates
- Architecture: expect updated draft by next week
- Information Model: expect updated draft by the virtual interim
- Data Models (both Moran and Birkholz): expect updated draft by the
  virtual interim

  Hannes: Need to get more companies in the conversation
  Dave W.: Need convergence between historic work and our current
     efforts.  Henk's draft is an example of how we can drive that
     convergence.  CoSWIDs can help with management functions; it has
     some adoption with industry in XML format.  We can arrange a
     presentation at the virtual interim.  Henk made several
     improvements to the DM too.

- Milestones: Chairs will work with AD to add architecture milestone.

  Hannes: Who will be in Bangkok and participate in the Hackathon?
  -- 4 or 5 hands went up
  -- There will also be a couple remote participants.
  -- Chairs will pose question to the list.