Minutes interim-2018-suit-01: Mon 07:00
minutes-interim-2018-suit-01-201802260700-00

• Status
• Email expansions
• History

• Versions
• 00

Meeting Minutes
minutes-interim-2018-suit-01-201802260700

   SUIT Virtual Interim, 2018/02/26

People present:
        Andrzej Puzdrowski
        Antonio Langiu
        Antti Kolehmainen
        Ari Keranen
        Avri Doria
        Bjorn Hjelm
        Brendan Moran
        Brian Haberman
        Carsten Bormann
        Dave Thaler
        Hannes Tschofenig
        Henk Birkholz
        Juan Carlos Zuniga
        Klaus Hartke
        Marco Tiloca
        Markus Gueller
        Michael Richardson
        David Waltermire
        Peter Koch

- Agenda bashing, Logistics -- Chairs (5 min)

- WG status -- Chairs (5 min)
Summary:
        Dave Waltermire welcomed everyone to the newly formed SUIT WG.
        The WG then discussed participation at the IETF 101 Hackathon.
Detailed discussion:
        Henk, Hannes, and Brendan all reported they would be there for SUIT.
        Ari, Carsten, and Hannes all reported they would be there for WISHI.
        It was suggested that SUIT and WISHI either share a table or have
        adjacent tables, depending on the number of people.
Acton items:
        ACTION ITEM (Hannes): WISHI hackathon, colocate - Hannes will setup a
        wiki entry

- ITU-T-SG-17-TSB Liaison Statement -- Chairs (10 min)
Summary:
        Dave Thaler led a discussion of the liaison statement received from
        ITU-T SG 17. The statement says it is for our information, not a
        request for action or a question asking for a response.  SG 17 has a
        work item in progress that the statement says covers requirements,
        architecture, and a high-level update procedure sequence.  The WG
        interpreted this explanation as not including a detailed protocol.  
        The liaison statement also explained SG 17’s taxonomy of roles from its
        document: Device Core, Communicator, Status Tracker, and Firmware
        Server. The WG discussed these four roles and they seem to make sense
        for IETF to use as well, although "Update Server" is also used by some
        IETF drafts (such as the arch draft discussed in the next agenda item)
        as a synonym for a Firmware Server. Hannes reported that OMA also has
        terminology for various roles.
Detailed discussion:
        ?: Consider thanking for providing this info
        ?: Ask for them to keep us up-to-date on any progress
        Henk: Consider adopting the terminology
        Dave: It would be useful for several SDOs to use the same terminology.
        Take this into account when writing our documents. Hannes: OMA has
        worked on a device management solution, with a software update
        mechanism that is similar to the ITU-T approach. Hannes will post the
        OMA terminology WG will provide other terminology from other SDOs Dave
        W. will talk with Takahashi about the ITU-T liaison statement. Hannes:
        Will you write back thanking them? Dave: We should wait until we have
        something to update them on (e.g., adopting a draft). Dave: We need to
        talk to other IETFers that are working in the ITU-T on this.
Action items:
        ACTION ITEM (Hannes): report back to the WG on OMA’s terminology for
        roles ACTION ITEM (anyone): any other WG members please provide other
        terminology from other SDOs ACTION ITEM (DaveW): Dave W. will talk with
        Takahashi about the ITU-T liaison statement.

- Discussion of proposed work (90 min)
  - draft-moran-suit-architecture-01
Summary:
        Most of the time was spent on discussion of this document which was
        recently updated in response to WG feedback (e.g., to use CBOR/COSE),
        and the authors proposed it for adoption by the WG for the architecture
        document charter milestone.  Brandan and Hannes walked through the
        various use cases and architecture components (see slides).  Overall
        feedback was positive, but the WG provided additional feedback to the
        authors.  For example, the coverage of counter-signing is lacking,
        based on list discussion. The authors agreed to update the document in
        the next few days with the feedback from the interim meeting. The
        meeting participants believed that the document was a good starting
        point, and has sufficient completeness and author cycles to be
        considered for WG adoption.   The WG understands there was another
        architecture document (Nandakumar’s) but that document is less
        comprehensive, has not been updated for some time, and had no
        proponents at the interim meeting.
Detailed discussion:
        Slide 5:
        Dave T.: Counter-signing can provide a means for operators to
        selectively authorize what software may be deployed. Transport security
        can provide further access control to allowed software for deployment.
        Carsten: Operators need to control what specific software is allowed to
        be deployed Dave T.: Who checks the signature. The communicator? The
        device on which the software will be deployed? Brendan: This slide was
        not intended to go to this detail Dave T.: Ok. We need to make sure it
        is well understood how the manifest fits into transport security and
        code signing? Hannes: Do we need to sign the manifest twice by the
        developer and operator? We don't have much text on this yet. Dave T.:
        There is consenus that we need to support multiple sigantures. Hannes:
        We need more text on this. Slide 6: Dave W: Is the hash discussed here
        in the signature or a digest of the software. Brendan: The manifest
        contains many hashes (e.g., over the software, signature over the
        manifest) Hannes: We are talking about the hash in the signature here.
        Carsten: Should we treat the contents of the manifest as claims or as
        metadata? The device needs to analyze these claims. Henk: A minimum set
        of data needs to be required. Hannes: Do we need to change terminology
        or make a more fundimental change? Carsten: No change, but we should
        think about these as a set of claims as a mental model. Hannes: Ok. We
        can try to rephrase in this style to make it easier to understand.
        Slide 7: Dave T., Dave W.: This is a simplified architecture. There may
        be other, more complex paths. Brenan: The key point here is the notion
        of end-to-end security through an untrusted intermediary. ALL:
        Consensus that we need more in diagrams to discuss encapsolation of the
        firmware in the manifest, second authors, and other components (e.g.,
        communicators). Slide 8: Markus: How would you manage the decryption
        keys? Hannes: The content decryption key would be included/referenced
        in the manifest for the specific device. Dave T.: The device should not
        have to download a bunch of information that does not pertain to the
        device. The manifest must be decomposable to support this. Brendan:
        Providing a URL for the device to lookup its key is a way to support
        this. On a USB device, a table can be used to lookup the key for a
        device. Dave T.: I am good if this lookup is not burdensom. Hannes: We
        need to highlight the issues around these use-scenarios. Any feedback
        on the Architecture? Poll: Have you read the architecture? 6 hands
        raised Question: Do the authors believe the draft is a good starting
        point for WG adoption? Dave W.: We need to ask about other architecture
        drafts. We have both draft-moran-suit-architecture-01 and
        draft-nandakumar-suit-secfu-solution-arch-00. Chairs: Start the
        adoption call after the next version of
        draft-moran-suit-architecture-01 is posted on the list to conclude at
        the meeting at IETF 101, unless we hear that
        draft-nandakumar-suit-secfu-solution-arch-00 is a going concern.
Action items:
        ACTION ITEM (Brendan): Update document to reflect meeting discussion
        ACTION ITEM (DaveW): Ping Nandakumar to check the status and intent of
        the authors of the other draft ACTION ITEM (Chairs): Start a call for
        adoption after that, to conclude during the London IETF meeting.

  - draft-moran-suit-manifest-01
  - draft-ietf-sacm-coswid-03
Summary:
        Only a brief period of time was spent on these due to lack of time.  A
        quick run-through of two proposals was done, but there was not time for
        deep discussion, so further discussion was deferred to the London
        meeting and mailing list.