Minutes IETF100: suit
minutes-100-suit-00

SUIT BoF at IETF 100 in Singapore
Monday, 13 November 2017 at 15:50

Note Taker: Michael Rosa
Jabber Scribe: Stephen Banghart
 
Jabber: xmpp:suit@jabber.ietf.org?join
MeetEcho: http://www.meetecho.com/ietf100/suit
Etherpad: http://etherpad.tools.ietf.org/p/notes-ietf-100-suit


AGENDA
 
Agenda bashing, Logistics -- Chairs (5 min)
Review of proposed charter text -- Chairs (10 mins)
Charter discussion (45 mins)
Discussion of new work items (20 mins)
  Hannes Tschofenig
    draft-moran-suit-architecture
    draft-moran-suit-manifest
  Suhas Nandakumar
    draft-nandakumar-suit-secfu-requirements
    draft-nandakumar-suit-secfu-solution-arch
Review of milestones & wrap up -- Chairs (10 minutes)


AGENDA BASHING AND LOGISTICS 
 
Co-Chairs are Dave Waltermire, Russ Housley, and Dave Thaler.
 
Russ was unable to make it to this meeting, so Dave Thaler stepped
in. (Thanks!)
 
Participants were reminded about the IETF Note Well.

The chairs will extend charter discussion instead of new work items
if necessary.
 
No agenda bashing by anyone.


REVIEW OF PROPOSED CHARTER TEXT

The proposed charter under review, and it is on the IESG Telechat
agenda for scheduled 30 November 2017.  Hopefully it will progress
quickly.
 
Out of scope: This effort does not intend to define a transport
protocol.
 
Someone asked what the co-chair means when he says "we".  He meant the
proponents of the proposed SUIT WG.
 
Cullen Jennings via remote was looking for greater clarity on transport
scoping.  The SUIT WG would not define new transport protocols, but the
WG could specify intreoperabiltiy or security issues pertaining to use
of existing transport protocols for software update.


SUIT WG CHARTER DISCUSSION

The proposed SUIT WG charter text can be seen at
https://datatracker.ietf.org/group/suit/about/

Discussion of the proposed SUIT WG charter text:
- Someone asked a question on Class 1 device. Do we assume that the
  device has the energy to actually do the transfer.  Answer: Yes.
- Paul Hoffman: Not sure if RFC 4108 is appropriate for starting just 
  because it exists.  Suggest removing RFC 4108 from charter.
- Suggestion from mic to use the plural form of the word "binary" to
  accomodate multi-part firmware loads.
- Bret Jordan: Prefer the alternate text offered by Paul Hoffman that
  does not require the work to begin with RFC 4108.  That said, I fully
  support this effort.
- Erik Nordmark: RFC 4108 already supports multi-part firmware loads. I
  do not understand what "script" means in the final paragraph.
- Hannes Tschofenig: I want to respond to Erik's question.  The intent
  was to limit the scope to exclude things like Javascript.
- Alexandre Petrescu: Prefers the text offered by Paul Hoffman. It better
  reflects the discussions on the mail list.
 
Discussion of the overlap with the proposed charter text for the TEEP
(Trusted Execution Environment Provisioning) BoF:
- TEEP BoF will meeting at 13:30 on Wednesday Afternoon
- Erik Nordmark: TEEP has a more complex model abut who is authoritative
  for what.
- Hannes Tschofenig: Agreement for proposed approach. TEEP will have a
  primary focus on smart phones, which have a unique operating system
  architecture.
- Emmanuel Baccelli via remote: Need to clean up usage of "software" and
  "firmware".  Need to recognize a firmware load might not replace the
  bootloader code; that remains in place.
- Alexandre Petrescu: Likes the separation between firmware and software.
- David Brown via remote: Class 1 devices might not have a separate
  trusted execution environment and an untrusted execution environment.

Delayed questions from Jabber on proposed SUIT WG charter text:
- Suhas Nandakumar via remote: Why are we restricting to one encoding
  format one we agree on the things that need to be encoded?
- Hannes Tschofenig: there is a desire to have one trustworthy parser.
- Paul Hoffman: There is a long history where the IETF Security Area has
  specified multiple formats, and the result was a failure for any of
  them to get adopted. It would be better to stay with one format.
- Someone expressed a desire to have automatic downgrade, and it is not
  clear whether a topic like this is allowed by the charter.
- Martin Thompson: I have a question on process about how edits will be
  made to reflect today's discussion.
- Dave Thaler as co-chair: I want to hear from everyone in the mic line
  so that we understand where there is consensus.
- Jari Arkko: I think this work is useful and interesting. I wonder if
  the work can be designed to support separate owner and manufacturer
  authorizations for updates. I would like to see charter text that
  deals with loading updates after manufacturers go out of business or
  end support.
- Cullen Jennings via remote: Need to clarify the capabilities of the
  bootloader instead of the class of IoT device.
- Alain Durand: Is the choice of the type of identifier in scope?
- Dave Thaler as co-chair: It is in scope if its necessary for one of
  the items mentioned in the charter text.
- Alain Durand: Are the selection of multiple transports in scope?
- Dave Thaler as co-chair: A new transport will not be defined, but it
  is okay to specify how an existing transport will be used.
- Hannes Tschofenig: Regarding Jari's point, a device may have multiple
  "manufacturers" are involved with building any particular device. So,
  Who is allowed to update the firmware is a policy decision.
- Hannes Tschofenig: Regarding Cullen's previous statement about the
  bootloader, thinks that Class 1 is sufficient to identify the type of
  devices that will be addressed by the SUIT WG deliverables.
- Erik Nordmark: The "manifest" talked about in the charter flows into
  the device.  There may be a need for a few bits to represent the
  capabilities of the device, such as the ability to revert back to the
  previous firmware download.
- Shawn Cooley: This group should not focus on the way that an update is
  formed because the difference between IoT devices is so vast. Just
  tell how to sign and encrypt. That said, work on discoverability and
  transport will be very helpful to the IT folks that are managing the
  networks that connect these devices.
- Paul Hoffman: Regarding transports and discovery, I think the charter
  should say "the group will not devine any new transport mechanisms"
  and it should say  "the group will not devine any new discovery
  mechanisms".  This makes it clear that existing ones might be used.
- Comment from mic: Strongly question "Class 1 Device" terminology in
  the charter.
- Comment from mic: Would like to see clarification on what is "IoT" in
  this charter.
- Hannes Tschofenig: Regarding Shawn's point, some people that build
  IoT device operating systems are in the room and they have been
  posting to the mail list.  So, they do care.

Co-chairs determine consensus of the participants:
- Hum: Three posible choices regarding RFC 4108 in the charter:
  -- Use existing text with its reference of RFC 4108
  -- Remove all reference to RFC 4108
  -- Mention RFC 4108 in passing
  -- Strongest support for removing all reference to RFC 4108.
- Agreement that the specification should not have dependencies that
  are beyond the capabilities of a Class 1 device.
- Agreement that the the group should not specify any new discovery
  protocols.
- Hum: Should we avoid the development of new transport mechanisms?
  -- Yes
  -- No
  -- Strong support for not the defining a new protocol for the
     delivery of firmware.
- Hum: Should the charter have text to talk about device capabilities?
  -- Charter needs text
  -- Leave out of charter, but allow it in the to architecture
  -- Preference for no text in the charter about device capabilities.
- Hum: Should the charter restrict to one manifest format?
  -- Only one format
  -- Not restrict the number of formats in the charter
  -- Much stronger for allowing more than one.
- Hum: Should the charter have text on discovery of update servers?
  -- Charter needs text
  -- Leave out of charter, but allow it in the to architecture
  -- Stronger support for leaving the upgrade server discovery
     discussion to the architecture.
- Cullen Jennings via Jabber: I would like the charter to say, "The
  architecture should provide a way to discover the firmware server."


WAY FORWARD

The revised charter text will be brought to the mail list for further
review and comment.

If the group is chartered. it will meet at IETF 101 in London.

There was not time for discusion of the Internet-Drafts today.  Is there
interest in a virtual meeting for that purpose?  More than 25 raised
hands (including Jabber).